08:46immibis: Nova[m]: well idk the best solution either, just pointing out something to consider - program session restore probably shouldn't be an exclusive Wayland thing
08:46immibis: Command-line programs might also want to be restored
09:19wlb: wayland Merge request !375 merged \o/ (util: fix undefined behavior in wl_array_for_each https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/375)
09:19wlb: wayland/main: David Benjamin * util: fix undefined behavior in wl_array_for_each https://gitlab.freedesktop.org/wayland/wayland/commit/8a7ecd774c40 tests/data/empty-client.h tests/data/empty-code.c tests/data/empty-server.h tests/data/empty.xml src/wayland-util.h tests/scanner-test-gen.sh tests/scanner-test.sh
12:01Shinri: Hi all, I recently found my numlock and capslock don't work well in Wayland, when I switch to an app like Firefox, neither of these two keys work correctly
12:02Shinri: I've tested qt, gtk in mutter, wester and Kwin but nothing works, it just appear like this
12:04Shinri: * like this: https://bugs.kde.org/attachment.cgi?id=167887
12:04Shinri: It frustrates me for days and I don't know where to start to debug this...
12:05Shinri: * I've tested qt, gtk in mutter, wester and Kwin but nothing works, it just appear like this: https://bugs.kde.org/attachment.cgi?id=167887
12:05Shinri: And I reported the details here: https://bugs.kde.org/show_bug.cgi?id=484655
12:05Shinri: * I've tested qt, gtk in mutter, wester and Kwin but nothing works, it just appear like this: https://bugs.kde.org/attachment.cgi?id=167887
12:05Shinri: And I reported the reproducing details here: https://bugs.kde.org/show_bug.cgi?id=484655
12:06kennylevinsen: You're on IRC, every time you edit your message it is sent again which makes this sequence hard to read
12:06Shinri: im sorry
12:07zamundaaa[m]: Shinri: try checking with WAYLAND_DEBUG what information apps are getting
12:07zamundaaa[m]: Like so: `WAYLAND_DEBUG=1 dolphin 2>&1 | grep modifiers`
12:08zamundaaa[m]: If you have all modifiers disabled, you should see something like wl_keyboard#25.modifiers(1092, 0, 0, 0, 0) when you focus the window
12:08zamundaaa[m]: And when numlock is enabled, it should be wl_keyboard#25.modifiers(1092, 0, 0, 16, 0)
12:25Shinri: <zamundaaa[m]> "Shinri: try checking with..." <- I retrieved the log and posted it here: https://invent.kde.org/-/snippets/3055
12:27zamundaaa[m]: From the Wayland side, everything looks correct
12:28zamundaaa[m]: Most likely your xkb configuration is to blame. As I don't know a lot about xkb, take that with a grain of salt though
12:33Shinri: thanks, i will try it
12:51wlb: wayland Merge request !376 opened by Chloé Vulquin (toast) Draft: xcursor: prevent recursive inherit loops https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/376
13:19wlb: wayland/main: Jordan Williams * egl: Disable symbols check for static builds https://gitlab.freedesktop.org/wayland/wayland/commit/262148403786 egl/meson.build
13:19wlb: wayland Merge request !373 merged \o/ (egl: Fix symbols check for static builds https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/373)
13:22emersion: ifreund: would you have time to update this? https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/374
13:23ifreund: oh, must have missed the review. Just a minute
13:23wlb: wayland/main: Simon Ser * scanner: add new enum-header mode https://gitlab.freedesktop.org/wayland/wayland/commit/fbd7460737c9 src/scanner.c
13:23wlb: wayland/main: Simon Ser * tests: add scanner test for enum-header https://gitlab.freedesktop.org/wayland/wayland/commit/2e0dbb7021f7 tests/ data/example-enum.h scanner-test-gen.sh scanner-test.sh
13:23wlb: wayland Merge request !312 merged \o/ (scanner: add new enum-header mode https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/312)
13:25ifreund: emersion: done :)
13:25emersion: ty
13:30wlb: wayland/main: Isaac Freund * wl_touch.cancel: document lack of frame event https://gitlab.freedesktop.org/wayland/wayland/commit/4945f2664fce protocol/wayland.xml
13:30wlb: wayland Merge request !374 merged \o/ (wl_touch.cancel: document lack of frame event https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/374)
13:30Nova[m]: <immibis> "Nova: well idk the best solution..." <- after talking with friends i think the best thing to do is a d-bus service and env var, making in total an XDG base spec
13:30Nova[m]: but idk how to... propose a base spec
13:30Nova[m]: who do you talk to?
13:32vyivel: Nova[m]: open an issue for https://gitlab.freedesktop.org/xdg/xdg-specs/?
13:32Nova[m]: oh an issue, duhh
13:33Nova[m]: hmm i don't see any issues proposing new specs
13:36vyivel: proposals seem to be in merge requests actually
13:37Nova[m]: ah shoot but idk how to do fancy spec language
13:38emersion: you can take inspiration from my cursor spec ;)
13:38emersion: (no)
13:38Nova[m]: you mean the one that just goes "look at the cursor spec"?
13:38Nova[m]: :p
13:39Nova[m]: anyway i know how this spec would work in proposal and i can make prototypes of it and all
13:39Nova[m]: and i even have proof that it works given the stardust protocol basically does the same thing
13:40emersion: the one that's closer to a rap lyrics sentence than a spec
13:40emersion: there should be more rap songs based off of spec text
13:41Nova[m]: :blobcatnod:
14:35wlb: wayland Merge request !377 opened by Simon Ser (emersion) util: convert macros to inline functions https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/377 [IPC library]
14:42wlb: wayland Merge request !378 opened by Simon Ser (emersion) ci: turn more warnings into errors https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/378 [Build system], [Testing]
14:57immibis: emersion: have you seen Dr Seuss rap?
17:11Company: after the fractional scaling fun with GTK for the last few weeks, I've come to 2 conclusions about fractional scaling:
17:12Company: 1. fractional scales should be thought about as a fraction of 2 integers, and both those integers should be small
17:12Company: ie 3/2 instead of 150%
17:13Company: and they should never be something like 329/120
17:13Company: 2. the numerator of that fraction should divide both the width and height of the monitor's pixel resolution
17:15Company: that ensures that you end up with an integer for the scaled monitor size, which means fullscreen windows have an integer size
17:16Company: and if you make sure your panel has a proper size, maximized windows end up with an integer size, too
17:19ManMower: I find fractional scaling looks best when the numerator is a multiple of the denominator.
17:19Company: there's still a bunch of issues with making that approach work well - like the fact that the forced 120 denominator in the protocol means you cannot use 7 or 9 or 16 as your denominator (no idea why you'd want to use 7, but I could imagine 9 or 16
17:19zamundaaa[m]: Company: ensuring that you always end up with integers is not really possible
17:20Company: and the fact that the buffer rounding algorithm often doesn't work as scales get close to 2
17:20Company: zamundaaa[m]: why not?
17:21zamundaaa[m]: Because you have a lot of different sizes where it all needs to work. Width, height of the screen, height of the panel + height of the maximized window, width of windows tiled in various configurations, or just aligned next to each other manually by the user
17:22zamundaaa[m]: Depending on the window decoration, you additionally get 2px line additions to a lot of these sizes
17:23zamundaaa[m]: that said, adjusting the scale is something I've thought about too, but on a per window basis
17:23Company: sure, in those cases you need to get creative, but with (1) you can ensure that the panel doesn't look too bad and adjust the configurations slightly so that they fit
17:23zamundaaa[m]: The compositor can't really do it that well, but a toolkit could nudge it a bit in one or the other direction when rendering
17:23Company: at least I think you can
17:24psykose: ManMower: isn't that just not fractional? those are whole integers
17:24ManMower: psykose: must be why it looks so nice. ;)
17:24psykose: ...
17:26mclasen: the numerology with 120 is nonsense
17:26Company: zamundaaa[m]: my example is always 1440p, because 2560 is not divisible by 3
17:27Company: zamundaaa[m]: so you probably don't want to offer 150% as a scale factor there
17:28Company: and instead pick a fraction that's close but does divide 2560
17:29Company: 5/3 maybe or 16/10
17:39kennylevinsen: The alternatives wasn't better. 255 made common values borked, and i doubt the aggressive resolution of a uint32 denominator would do anyone any good.
17:40zamundaaa[m]: higher resolution couldn't have made it worse in any way
17:40kennylevinsen: Doesn't mean it would make it better in any way :)
17:41mclasen: I don't see any problems with just sending a proper fraction
17:41mclasen: its not like we're size limited
17:43kennylevinsen: Of course not, but what is the use case that is not reasonably handled by a fixed denominator?
17:44Company: all the numbers that aren't divisible by 120
17:44kennylevinsen: (granted, the decision for 120 over wl_fixed sometimes keeps me up at night, but the author of wl_fixed also protested against its use as 255 is a terrible denominator)
17:44Company: technically, a fixed numerator would be way less problematic
17:45kennylevinsen: Company: and you need 100.83% scaling?
17:45Company: I need a scale factor close to 150% that divides 2560 and 1440
17:47mclasen: the whole idea of sending scale factors is questionable, imo. Because it makes for endless games with rounding modes
17:48Company: closest one you can get is 160/107, but if the denominator is forced to be 120, I think 16/10 is the closest you can get?
17:48kennylevinsen: that's true, and for all intends and purposes it was a workaround to proceed
17:49kennylevinsen: mclasen: but it's also rather unwayland-like to have the compositor control dimensions, so the client has to be able to come up with the right buffer dimensions one way or another
17:51kennylevinsen: zamundaaa[m]'s proposal was to effectively allow the client to operate in coordinate space matching the physical coordinates of a particular monitor, but I believe that stalled
17:52kennylevinsen: I imagine we'll have gathered enough complaints^W thoughts for a v2 at some point.
17:52Company: "at some point" will probably be rather soon
17:52Company: once Gnome's fractional scaling hits the distros
17:53zamundaaa[m]: well, I thought I had gathered enough two years ago, but yes, we've now also seen these issues in practice
17:53Company: or I guess KDE6?
17:53zamundaaa[m]: I have been working on fractional scaling stuff again and will update the MR + implementation soon
17:53Company: does KDE6 do the full fractional dance from compositor to client?
17:54kennylevinsen: two years ago Gtk also said fractional scaling would be practically impossible before Gtk5, so we had a smaller pool of interested parties for discussion
17:54zamundaaa[m]: v2 didn't fail to succeed because of the client side really, it was mostly compositor developers that weren't happy about it
17:55Company: (it was a contentious topic in GTK, but I tricked them all!)
17:55Company: because GTK still doesn't do fractional scaling really
17:55Company: GTK's renderer does though
17:55zamundaaa[m]: Company: what do you mean with "the full fractional dance"?
17:55kennylevinsen: Even in the current state I'd say we're in a much better place than we used to - our common attitude used to be that fractional scaling was an impossibility, now we have tried it and can improve it...
17:56Company: zamundaaa[m]: the compositor offers fractional scales in its configuration and the panels clients render to that chosen scale factor (instead of downscaling from 2x)
17:57kennylevinsen: zamundaaa[m]: I'll need to look at the proposal again, I forget the details
17:57Company: *panels and clients
17:57Company: I think the proposal was better, but I'm not sure it solved the bigger problems
17:57zamundaaa[m]: Company: all Qt 6 apps do fractional scaling, yes
17:58Company: and kwin does it, too - and KDE6 is Wayland, so it works there, too
17:59Company: which means we're all currently waiting for the April distro release when millions of people will try it and find all the issues
17:59Company: (on top of the ones that people have already found)
18:00zamundaaa[m]: People have been using Plasma 6 on Arch and on prerelease Fedora 40 for a while and we haven't had too many complaints about fractional scaling
18:01zamundaaa[m]: There's even users that say it's better than Windows already
18:01Company: it is absolutely better than windows
18:01Company: because any form of scaling on windows is a catastrophe
18:02zamundaaa[m]: Nah it works quite well, at least as long as you only have one display
18:03zamundaaa[m]: If you have two with different scaling and move windows between them, that is really terrible
18:03Company: my favorite thing about Windows is that the old Winamp I'm still using isn't scaled, so it's about as big as the firefox titlebar
18:04Company: and if they also have different refresh rates and fullscreen stuff, Windows falls apart entirely
18:04Ermine: fractional scaling is good as long as xwayland is not involved...
18:06Company: zamundaaa[m]: Gnome still runs into stuff like https://i.redd.it/rr1ybxup1sqc1.png
18:07zamundaaa[m]: We do have gaps between the panel and maximized windows at some scale factors too
18:08Company: I wonder what Windows does there
18:08zamundaaa[m]: Windows uses device pixels
18:09zamundaaa[m]: What toolkits on Windows do to deal with that though I don't know
18:10Company: neither do I - but knowing the state of the GTK backend, it probably rounds one way or the other
18:10Company: likely it doesn't offer fractional scales even
18:11zamundaaa[m]: For the vertical size case specifically I've had the idea of masking the issue by scaling the title bar a little bit, which would work with server side decorations at least
18:11zamundaaa[m]: It might be that the system library that paints the title bar in Windows does something like that too
18:11LaserEyess: fwiw, windows 10 at least has those same "off-by-one" errors for certain things, too
18:11LaserEyess: especially with title bars
18:15Company: zamundaaa[m]: I would scale the title bar, too, so it fills that seam. I might even adjust the scale factor of the panel to make it look good
18:15Company: but I'll leave that up to the shell guys to figure that out
18:15Company: it's why I want small numbers in the numerator
18:15Company: so rounding to the next pixel boundary isn't too big of a difference
18:15Company: and then you have integers for both and avoid problems
18:15Company: *integers in application space
18:16Company: it's tricky to get that right with my example above of course
18:17Company: if you want to offer 150% on 1440p, you'll not have integers
18:18Company: but if you go with 166% or 133%, you have 5/3 or 4/3 and then you can scale the panel to a multiple of 5 or 4 pixels and you don't have seams
18:21Company: and that approach works for fancier setups with multiple panels, too
18:22Company: but it does restrict the scale factors you can offer
21:50wlb: weston Issue #897 opened by Oleksii Khudobin (alexey.khudobin) Some nested compositors (KDE) failed to work with weston when backend is RDP https://gitlab.freedesktop.org/wayland/weston/-/issues/897