ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
shoragan has joined #wayland
shoragan has quit [Read error: Connection reset by peer]
shoragan has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
kasper93_ has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
kasper93 has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
kts has joined #wayland
iomari892 has joined #wayland
iomari891 has quit [Read error: Connection reset by peer]
plutoneun has quit [Remote host closed the connection]
sima has joined #wayland
RAOF has quit [Remote host closed the connection]
RAOF has joined #wayland
RAOF has quit [Remote host closed the connection]
RAOF has joined #wayland
kts has joined #wayland
plutoneon has joined #wayland
kts has quit [Quit: Leaving]
plutoneon has quit [Remote host closed the connection]
plutonuon has joined #wayland
rv1sr has joined #wayland
iomari892 has quit [Ping timeout: 480 seconds]
<zubzub>
ramblurr: if you need anything from me to publish the project or whatnot, just let me know, it's been a while since I worked on that :)
tzimmermann has joined #wayland
iomari891 has joined #wayland
<ifreund>
geemili: nice!
leon-anavi has joined #wayland
rasterman has joined #wayland
coldfeet has joined #wayland
___nick___ has joined #wayland
<bluetail>
I have tried a couple of colorpickers on wayland sway and only hyprpickr did work (with proper precision). I need to be compliant with color contrast. Unfortunately, this means I am running a VM to run https://www.tpgi.com/color-contrast-checker/ Is there anything that does this in comparable quality, or is this just because we lack proper tooling
<bluetail>
on Wayland?
<kennylevinsen>
what's wrong wth hyprpickr
<bluetail>
Hyprpickr does work but it's nothing like a proper Colour Contrast Analyser. So it would have to be integrated and it's a bit of work to be done. I am complaining about that I had to try so many and only one worked.
<bluetail>
If you wanted to improve hyprpicker, you would require to integrate keyboard movement within the preview because selecting the exact pixel with the mouse is a nuisance sometimes.
<kennylevinsen>
hyprpickr working makes it clear that everything needed for such a thing to work is already there, so it's "just" a matter of someone wanting to write a dedicated color contrast tool
<kennylevinsen>
after all, a color picker is just a thing that takes a screenshot and lets you inspect color values within it. That's what hyprpickr is doing.
<bluetail>
Correct. About CCA from TPGi : There was a time where specific versions were required at work. That is no longer the case. I do wonder if they have a secret sauce to determine the result. I hope they do not. In any case, it really should be doable. I have some knowledge gaps in "Lightness" however. Stuff that would be really great is "give next
<bluetail>
color that fulfills success criteria of AA or AAA level"
<kennylevinsen>
in floating point colors, there are infinite colors that live up to the contrast criteria. Limited to 24-bit colors, there's still quite a few: I don't know how they defined their contrast test, but you just need the distance between two colors in the color space to be large enough
<kennylevinsen>
so not sure how you'd give a single "next color"
<kennylevinsen>
but if you tell it your color scheme, it could probably have it give you "*an* acceptable background color close-ish to my color scheme"
<kennylevinsen>
if it's only allowed to tune luminosity of the same color then it would be easy enough though
MrCooper has quit [Remote host closed the connection]
<Wulf>
I've got a framework-laptop running debian unstable. An external monitor is connected from the USB-C port on my laptop to the monitor's mDP port. When I switch the monitor off/on or change its input, it's not detected unless I plugout/in the cable. Is there any command to rescan for monitors or any way to debug this issue and fix it for good?
fmuellner has joined #wayland
<ramblurr>
zubzub: thanks! at some point i'll want to publish to maven central, but not yet
<ramblurr>
could someone clarify what all the variations of wl_marshal_* are for and when they should be used? It seems like they aren't all actually needed, though wayland-scanner uses different ones
andymandias has quit [Remote host closed the connection]
andymandias has joined #wayland
andymandias has quit [Remote host closed the connection]
iomari891 has joined #wayland
nerdopolis has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
ecraven has joined #wayland
<ecraven>
hello ;)
<ecraven>
how do I talk to "wayland"? in x11, I can open a unix domain socket and send binary packages over that. does wayland work the same way?
<soreau>
wayland compositors communicate over a unix domain socket, yes
<soreau>
you can see the traffic by running WAYLAND_DEBUG=1 wayland-app from a wayland compositor
<ecraven>
is there a way to run a wayland compositor "inside" my X11, to play around with? like Xnest or Xephyr?
<emersion>
many wayland compositors support running inside X11
<ecraven>
without "taking over"?
<emersion>
as an X11 window
<ecraven>
perfect, thank you!
<ecraven>
any recommendations on *which* to try?
<kennylevinsen>
depends on taste - sway has excellent nested support, weston also has it
<ecraven>
thanks, I'll try one of these then!
lsd|2 has joined #wayland
lsd|2|2 has joined #wayland
lsd|2 has quit []
lsd|2|2 has quit []
Calandracas has quit [Ping timeout: 480 seconds]
Calandracas has joined #wayland
rv1sr has quit []
andymandias has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
rv1sr has joined #wayland
<vnd>
daniels: --use-pixman didn't help, but the problem turned out to be somehow caused by browser startup timing
<vnd>
starting browser at the same moment as in the previous yocto release resulted in invisible browser window (but logs look good) and broken weston-screenshooter
<vnd>
starting browser 5 seconds later somehow helped ¯\_(ツ)_/¯
coldfeet has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
cmichael has quit [Quit: Leaving]
WhizzWr has joined #wayland
kasper93_ has quit [Remote host closed the connection]
glennk has joined #wayland
Calandracas has quit [Ping timeout: 480 seconds]
<tkna>
Hi, A simple question: is it possible in principle to get the text of an application window in Wayland if you have root privileges? This is a question that came to mind thinking about how possible it is for a screen reader to support Wayland.
Calandracas has joined #wayland
<soreau>
that sounds like a job for something like gtk's atk
Wulf4 has joined #wayland
<mclasen>
tkna: look for the newton prototype
<tkna>
soreau, mclasen: I see, is there a lot of development going on? I will look into it. Thanks kindly.
___nick___ has quit [Remote host closed the connection]
lsd|2 has quit [Ping timeout: 480 seconds]
lsd|2 has joined #wayland
<bl4ckb0ne>
colinmarc: what about trigger as axis, and button/pressure merged into one
<bl4ckb0ne>
regular buttons can do 0 and 1, and pressure sensitive can do a value between 0 and 1
<colinmarc>
so one enum for axis, and one enum for button/pressure?
<colinmarc>
that makes sense to me
<colinmarc>
we just have to specify that the button event is required, but the pressure event is optional
<colinmarc>
hm except, triggers are pressure-sensitive buttons in this scheme?
<bl4ckb0ne>
hm yeah
<colinmarc>
I would just have a third enum for triggers, honestly. it's more explicit
<bl4ckb0ne>
wdym
<colinmarc>
a trigger event, and a trigger_source enum
<colinmarc>
treat it differently from pressure-sensitive buttons. because most clients care about triggers, so they'll implement that event - but most don't care about pressure-sensitive buttons, so they can ignore that event entirely
<bl4ckb0ne>
I think id keep it as axis like sdl does
<colinmarc>
ok, so triggers and sticks are axes, that's one enum, and button/pressure has a separate source enum?
<colinmarc>
do we document that triggers only go from 0 to 1 instead of -1 to 1?
<colinmarc>
bl4ckb0ne: lol well, it is easier to type
<colinmarc>
also the word is less overloaded
* bl4ckb0ne
makes vim roar
<colinmarc>
btw, would sdl3 (wayland backend) be a good client/
<colinmarc>
s///?/
<bl4ckb0ne>
possibly, I know they have their own stuff with HID, convincing them to move a baked in WL solution might be hard, especially if we don't have rumble yet
<bl4ckb0ne>
but as a draft somewhere, definitely
* soreau
gives bl4ckb0ne forceful feedback
<soreau>
what if you made a drop-in replacement sw wl_js0 node, so that apps expecting a real node could use to get events only when the app has js focus
<colinmarc>
@_oftc_bl4ckb0ne:matrix.org btw, you have magic mirror listed as a client, but it's actually a compositor in this case :) also, you should probably update the description in general, because right now it talks about openxr
<soreau>
womp womp :P
<bl4ckb0ne>
first draft was loosely based on openxr
<bl4ckb0ne>
alright, ext-gamepad it is
<bl4ckb0ne>
hm wait no, wp makes more sense
<colinmarc>
would be a good candidate for the new experimental thing
<colinmarc>
but that's not merged yet I guess
<bl4ckb0ne>
yep
<bl4ckb0ne>
alright, 3rd iteration on the name
<colinmarc>
@_oftc_riteo:matrix.org wanted to do a godot impl, right?
andymandias_ has joined #wayland
andymandias has quit [Ping timeout: 480 seconds]
andymandias_ is now known as andymandias
<DemiMarie>
Would a rootless Wayland compositor be useful for RDP?
glennk has quit [Ping timeout: 480 seconds]
alarumbe has joined #wayland
karolherbst has quit [Read error: Connection reset by peer]