05:09 geemili: I just created a pure Zig Wayland library. Still very alpha, but it should be usable: https://git.sr.ht/~geemili/shimizu
06:58 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 :)
07:55 ifreund: geemili: nice!
08:42 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
08:42 bluetail: on Wayland?
08:44 kennylevinsen: what's wrong wth hyprpickr
08:46 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.
08:49 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.
08:52 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
08:53 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.
08:57 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
08:57 bluetail: color that fulfills success criteria of AA or AAA level"
09:23 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
09:24 kennylevinsen: so not sure how you'd give a single "next color"
09:24 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"
09:26 kennylevinsen: if it's only allowed to tune luminosity of the same color then it would be easy enough though
09:41 wlb: wayland-protocols Issue #218 opened by () protocol request: Analog keyboard https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/218
10:19 Wulf: Hello.
10:22 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?
10:30 ramblurr: zubzub: thanks! at some point i'll want to publish to maven central, but not yet
10:31 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
13:15 ecraven: hello ;)
13:15 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?
13:16 soreau: wayland compositors communicate over a unix domain socket, yes
13:16 soreau: you can see the traffic by running WAYLAND_DEBUG=1 wayland-app from a wayland compositor
13:18 ecraven: is there a way to run a wayland compositor "inside" my X11, to play around with? like Xnest or Xephyr?
13:19 emersion: many wayland compositors support running inside X11
13:19 ecraven: without "taking over"?
13:19 emersion: as an X11 window
13:20 ecraven: perfect, thank you!
13:20 ecraven: any recommendations on *which* to try?
13:20 kennylevinsen: depends on taste - sway has excellent nested support, weston also has it
13:21 ecraven: thanks, I'll try one of these then!
14:47 vnd: daniels: --use-pixman didn't help, but the problem turned out to be somehow caused by browser startup timing
14:48 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
14:48 vnd: starting browser 5 seconds later somehow helped ¯\_(ツ)_/¯
17:56 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.
17:57 soreau: that sounds like a job for something like gtk's atk
18:02 mclasen: tkna: look for the newton prototype
18:07 tkna: soreau, mclasen: I see, is there a lot of development going on? I will look into it. Thanks kindly.
18:08 mclasen: https://blogs.gnome.org/a11y/2024/06/18/update-on-newton-the-wayland-native-accessibility-project/
18:10 tkna: mclasen: It's nice. I'm looking forward to the future. Thanks!
20:25 bl4ckb0ne: colinmarc: what about trigger as axis, and button/pressure merged into one
20:25 bl4ckb0ne: regular buttons can do 0 and 1, and pressure sensitive can do a value between 0 and 1
20:27 colinmarc: so one enum for axis, and one enum for button/pressure?
20:27 colinmarc: that makes sense to me
20:27 colinmarc: we just have to specify that the button event is required, but the pressure event is optional
20:27 colinmarc: hm except, triggers are pressure-sensitive buttons in this scheme?
20:28 bl4ckb0ne: hm yeah
20:28 colinmarc: I would just have a third enum for triggers, honestly. it's more explicit
20:28 bl4ckb0ne: wdym
20:28 colinmarc: a trigger event, and a trigger_source enum
20:29 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
20:31 bl4ckb0ne: I think id keep it as axis like sdl does
20:32 colinmarc: ok, so triggers and sticks are axes, that's one enum, and button/pressure has a separate source enum?
20:32 colinmarc: do we document that triggers only go from 0 to 1 instead of -1 to 1?
20:35 bl4ckb0ne: i think so, SDL does t hat
20:35 bl4ckb0ne: https://github.com/libsdl-org/SDL/blob/SDL2/include/SDL_gamecontroller.h#L613
20:36 colinmarc: cool 👍️
20:37 bl4ckb0ne: huh, SDL3 went with `gamepad`
20:38 bl4ckb0ne: nice, they moved a/b/x/y to n/s/e/w
20:38 colinmarc: bl4ckb0ne: lol well, it is easier to type
20:39 colinmarc: also the word is less overloaded
20:39 bl4ckb0ne:makes vim roar
20:40 colinmarc: btw, would sdl3 (wayland backend) be a good client/
20:40 colinmarc: s///?/
20:42 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
20:42 bl4ckb0ne: but as a draft somewhere, definitely
20:47 soreau:gives bl4ckb0ne forceful feedback
20:52 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
20:53 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
20:54 soreau: womp womp :P
20:55 bl4ckb0ne: first draft was loosely based on openxr
20:56 bl4ckb0ne: alright, ext-gamepad it is
20:58 bl4ckb0ne: hm wait no, wp makes more sense
20:58 colinmarc: would be a good candidate for the new experimental thing
20:58 colinmarc: but that's not merged yet I guess
21:00 bl4ckb0ne: yep
21:05 bl4ckb0ne: alright, 3rd iteration on the name
21:06 colinmarc: @_oftc_riteo:matrix.org wanted to do a godot impl, right?
21:30 DemiMarie: Would a rootless Wayland compositor be useful for RDP?