ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
ManMower has quit [Ping timeout: 480 seconds]
The_Company has quit []
ManMower has joined #wayland
peeterm_ has joined #wayland
dottedmag has quit [Read error: Connection reset by peer]
mort_ has quit [Quit: Ping timeout (120 seconds)]
mort_ has joined #wayland
dos11 has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
sgm has quit [Ping timeout: 480 seconds]
peeterm has quit [Ping timeout: 480 seconds]
peeterm_ is now known as peeterm
sgm has joined #wayland
fossdd has joined #wayland
dos1 has quit [Ping timeout: 480 seconds]
Prf_Jakob has quit [Ping timeout: 480 seconds]
Prf_Jakob has joined #wayland
dottedmag has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
jess has joined #wayland
<jess>
hi
<psykose>
hi
Brainium has quit [Quit: Konversation terminated!]
psykose has quit [Remote host closed the connection]
psykose has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
<vaxry>
hi
jess has quit [Quit: Leaving]
<YaLTeR[m]>
hi
mxz has quit [Ping timeout: 480 seconds]
<lockywolf>
YaLTeR[m]: hello
glennk has joined #wayland
sima has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
mxz has joined #wayland
cnsvc has quit [Quit: %bye%]
cnsvc has joined #wayland
JakeSays1 has joined #wayland
JakeSays has quit [Ping timeout: 480 seconds]
kts has joined #wayland
klaasvakie has joined #wayland
ghishadow has quit [Ping timeout: 480 seconds]
d42 has quit [Read error: Connection reset by peer]
tzimmermann has joined #wayland
<klaasvakie>
Hi, I'm dealing with an issue with a USB barcode scanner that presents as a USB keyboard. When I scan a specific barcode I get the correct symbols with "evtest /dev/input/eventX", when I am in xorg, I get those correctly mapped and in the correct order when checking with "xev", but in wayland the keycodes sometimes arrive out of order when checking with "libinput debug-event --show-keycodes"
<klaasvakie>
Specifically, I am seeing SHIFT-L releases arriving early. I can reliably reproduce this. This is also architecture independent (manifests on ARM and x86_64). All machines running stock Gnome on ubuntu 22.04
<kennylevinsen>
Peculiar. I am unfamiliar with ibus. Regardless, libinput doesn't speak to Wayland. It's the library that Wayland compositors themselves use to manage evdev inputs, and its debug tools open evdev directly.
mblenc has joined #wayland
<klaasvakie>
looks like a fix was merged for gnome 45
<kennylevinsen>
That MR changes how Mutter reacts to events from libinput, it won't change anything if libinput or the evdev device was mistaken. Likewise, if this was the issue, the libinput debug tool wouldn't have shown it...
rasterman has joined #wayland
<klaasvakie>
yeah sorry - I'm not familiar with the internals of exactly how all the components fit together - first time going down this rabbithole
mblenc1 has quit [Ping timeout: 480 seconds]
sima is now known as Guest3147
sima has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
ghishadow has joined #wayland
kts has quit [Ping timeout: 480 seconds]
<kennylevinsen>
klaasvakie: try running evtest and libinout debug-events simultaneously
sima has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
bnason has quit [Quit: Ping timeout (120 seconds)]
bnason has joined #wayland
mvlad has joined #wayland
<klaasvakie>
logs from a simultaneous capture here:
<klaasvakie>
you can see the KEY_LEFTSHIFT (42) released arriving out of order on line 57 in the libinput trace
mblenc has quit [Ping timeout: 480 seconds]
<kennylevinsen>
Looks the same to me between libinput and evtest - shift press, g press, shift release, g release. Although I'm on a phone screen right now.
<kennylevinsen>
Line 196 is the same evtest event
<klaasvakie>
yeah - I agree with you
<klaasvakie>
The trace from both is also the same after a "pkill ibus"
<klaasvakie>
so I think the issue is happening elsewhere
JakeSays has joined #wayland
JakeSays1 has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
<kennylevinsen>
klaasvakie: which Wayland server?
mart has joined #wayland
<davidre>
I find it curious that evdev would send differnt events when using Xorg?
<MrCooper>
presumably that was a misunderstanding, the issue seems between ibus and the compositor?
Company has joined #wayland
garnacho has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
<klaasvakie>
MrCooper is correct - it was a misunderstanding, sorry for the noise
<klaasvakie>
the traces from libinput dump-events and evtest are identical between xorg and wayland, and with/without ibus killed
<klaasvakie>
I'm not sure how I came to the previous conclusion, I could've sworn I saw different stuff earlier, but alas.
<davidre>
No worries
<pq>
bwidawsk, an arbitrary time out of my hat, that I think should be long enough even on a heavily loaded CI machine without stalling CI failure too much.
<wlb>
weston/main: Jordan Williams * meson: Add missing dependencies on egl https://gitlab.freedesktop.org/wayland/weston/commit/2e6c58fb37ea libweston/backend-headless/meson.build libweston/backend-pipewire/meson.build libweston/backend-wayland/meson.build libweston/meson.build meson.build shared/meson.build
<zzag_>
jadahl: is there anything that we could to bump https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6212#note_2055560 ? GTK applications are not exclusive to GNOME Shell, they run on other desktop environments too. GTK not willing to commit to wayland protocols that are important to desktop environments other than GNOME Shell is deeply disappointing...
<zzag_>
another example is xdg-decoration-v1
<emersion>
oh :(
<emersion>
"Get it into mutter, then we'll look at it"
<emersion>
pretty disappointing indeed
<jadahl>
I don't know why mclasen has that opinion, I disagree
<emersion>
mclasen often has… opnionated opnions let's say…
<jadahl>
no idea the state of xdg-decoration though, I think I've reviewed a couple of iterations of some MR or two
<davidre>
> I will say that I don't think this protocol fits very well into Wayland, and I would be happier if mutter did not accept it.
<davidre>
....
<jadahl>
opinienated opinion :P
<kennylevinsen>
the best kind of opinion
<jadahl>
fwiw, I wouldn't block any mutter implementation, but not very high prio for me personally to implement
<d_ed[m]>
<jadahl> "I don't know why mclasen has..." <- Can you override him on this MR?
<kennylevinsen>
well, maybe not *override*, just share a second opinion perhaps
<d_ed[m]>
I mean override. This is beyond rude. I have a lot of Gnome specific patches in Qt that I do to be a good citizen. This is beyond rude.
<d_ed[m]>
* I mean override. This is beyond rude. I have a lot of Gnome specific patches in Qt that I do to be a good citizen.
<kennylevinsen>
yeah, but convincing them of the benefits of a friendlier standpoint might be preferable for future cooperation, if possible.
fmuellner has joined #wayland
<kennylevinsen>
otherwise, the next such MR will end up equally difficult, if not harder. It's not sustainable to have to take their family hostage every time, too cumbersome. :)
<jadahl>
going around "overriding" people is a rather antisocial behavior, not going to do that
<kennylevinsen>
d_ed[m]: minor nit: editing a message to remove duplicate sentances has the ironic side-effect of sending the whole message again on IRC. :D
<d_ed[m]>
jadahl: Sorry, I don't mean to take it out on you
<kennylevinsen>
your personal opinion whatever that may be would of course still be appreciated as input on the MR
<zzag_>
absolutely! ^
kts has quit [Quit: Konversation terminated!]
<Consolatis>
I would have thought that cursor shape would actually be great for gnome as it provides the option for a unified cursor theme controlled by the compositor for all applications that support the protocol
<Consolatis>
rather than hoping that applications use whatever is configured within the gnome environment / gtk theme
ghishadow has left #wayland [#wayland]
ghishadow has joined #wayland
zzag_ has quit []
zzag has joined #wayland
Brainium has joined #wayland
Fxzxmic has joined #wayland
Brainium_ has joined #wayland
Brainium has quit [Read error: Connection reset by peer]
Brainium_ has quit []
Guest3147 has quit []
sima has joined #wayland
Brainium has joined #wayland
leon-anavi has quit [Remote host closed the connection]
leon-anavi has joined #wayland
feaneron has joined #wayland
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
Fxzxmic has quit [Read error: Connection reset by peer]
Fxzxmic has joined #wayland
CME has quit [Ping timeout: 480 seconds]
CME has joined #wayland
<Company>
random question of the day: do subsurfaces work for cursor surfaces?
<pq>
nothing says they don't, but they probably don't, except in Weston
privacy has joined #wayland
<Company>
I was wondering how many things would fall apart and keep working if GTK aded a widget cursor
<emersion>
should work in wlroots, but yeah, i wouldn't rely on it
<pq>
what's a widget cursor?
<Company>
setting any GtkWidget as the cursor
<emersion>
cursor with an arbitrary widget tree in it i suppose?
<Company>
yeah
<Company>
which would mean you could put offloaded videos into it
<emersion>
you're going to have fun with X11 aha
<Company>
dnd icons work with X11
<Company>
and those are widgets
<pq>
nothing in Wayland stops you from doing so
<emersion>
but cursors in X11 are a completely separate thing?
<Company>
but I think that's just manually repositioning an XWindow to the pointer location?
<emersion>
like… you basically need to get a pixel array, and then send that to the X11 server
<Company>
sure, but we can just hide the cursor and put an override-redirect XWindow there
<emersion>
and the window follows the cursor manually?
<Company>
no, we'd have to make it do that
<emersion>
interesting, although it will lag behind
<Company>
that's expected with X11
<Company>
though our cursors have the ability to claim they're unsupported and then they use the fallback
<Company>
so the more realistic solution is that nobody implements it and waits for patches
kts has joined #wayland
<Company>
I think once the small desktops have switched to Wayland, GTK4's X11 backend is pretty dead
<YaLTeR[m]>
who is pushing gtk 4 x11 nowadays even?
kts has quit []
<Company>
nvidia users
<YaLTeR[m]>
understandable
Fxzxmic has quit [Read error: Connection reset by peer]
<YaLTeR[m]>
fwiw I'm gonna guess cursor with subsurfaces will work on Smithay too, modulo maybe the usual "nobody ran this code path before" fixes
<Company>
there's also the LTS distros, but I don't think they use GTK4 much
<Company>
so I expect GTK3 X11 to receive more attention than GTK4 X11
Fxzxmic has joined #wayland
<YaLTeR[m]>
One problem with the cursor is it goes into the cursor plane and that one's a dumb buffer, so you need to download from GPU to CPU
<Company>
current GTK only allows textures anyway
<jadahl>
Company: LTS distros use apps from e.g. flathub, so yes they might get new gtk4s
<Company>
jadahl: that's gonna explode sooner or later though - both because nobody maintains the X11 codepaths and because flatpak doesn't want to keep the X11 codepaths open
<emersion>
i use a GPU buffer for the cursor plane in wlroots
<Company>
I don't think widget cursors are that interesting
<Company>
unlike for dnd cursors - because being able to drag a widget is a neat feature
<Company>
it's rare that apps want to do fancy things with regular cursors
<Company>
exception as always: VMs
<jadahl>
Company: I mean Wayland
<pq>
YaLTeR[m], do you mean Smithay does per-plane partial compositions with GPU?
<YaLTeR[m]>
pq: I meant that if a cursor is a video then there might be performance issues involved
<pq>
and sub-surfaces?
<YaLTeR[m]>
Pretty sure smithay doesn't do per-plane partial compositions, it just picks the topmost cursor surface for the cursor plane probably
<YaLTeR[m]>
So if that happens to be a video subsurface then that's going into the dumb buffer
<Company>
YaLTeR[m]: how does that work with dnd?
<Company>
like, dnd has 2 surfaces already - the pointer from the compositor and the drag icon from the app
<pq>
sub-surface cannot be a cursor surface by definition, those are conflicting roles. Unless you mean something else?
<YaLTeR[m]>
Company: the API is that the compositor marks elements in the render tree as "cursor" or "something else" and if there's an element marked as cursor at the top then smithay will try offloading it into the cursor plane
<YaLTeR[m]>
Element means one wayland buffer
<Company>
so during dnd only half of the cursor ends up in the cursor plane?
<pq>
Company, what's "cursor"?
<Company>
pq: the thing that moves when you move the mouse
<YaLTeR[m]>
Company: if the compositor marks dnd as cursor, and if the cursor is next to a different monitor in such a way that only the dnd surface shows on that monitor but not the cursor, then that dnd buffer will be on that monitor's cursor plane
<YaLTeR[m]>
otherwise only the cursor yes
<pq>
so if I drag a window, the window is part of the cursor?
<Company>
YaLTeR[m]: that sounds like a wild corner case to go wrong :D
<YaLTeR[m]>
Company: i test all the corner cases :p
<YaLTeR[m]>
although here you might call it an edge case
<Company>
pq: that's an interesting question - though I think the dragged window doesn't follow the cursor exactly, so people don't associate it
<pq>
there's a wl_surface with the cursor role, and I guess there is also a wl_surface with the DnD icon role?
<Company>
pq: and it requires an active button press
mohit81582263 has quit [Quit: mohit81582263]
<Company>
but I don't think many people realize that the dnd icon is 2 different surfaces
<pq>
Company, in Weston the window will move in lock-step with the cursor, because Weston does not implement a special fast-path for cursor surface motion only. So it depends.
mohit81582263 has joined #wayland
<Company>
I think we had bugs to let people get of the stupid arrow when dragging things
<YaLTeR[m]>
in my compositor dnd never goes into the cursor plane because my app puts videos into dnd and i don't want the slow
<Company>
hahahaha
<Company>
tuned for the apps that matter!
<pq>
The same in Weston, only one wl_surface can go to the KMS cursor plane. Weston does not do partial composition yet, so that's all it can do.
<YaLTeR[m]>
yeah, no partial composition in smithay either i think, so in 99.99% of cases you'll have pointer on top anyway
mblenc has quit [Remote host closed the connection]
Fxzxmic has quit [Remote host closed the connection]
Fxzxmic has joined #wayland
eroc1990 has joined #wayland
larunbe has quit []
alarumbe has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
rv1sr has joined #wayland
marriedwithcode has joined #wayland
marriedwithcode has quit [Remote host closed the connection]
klaasvakie has quit [Ping timeout: 480 seconds]
molinari has joined #wayland
robert_mader has joined #wayland
<robert_mader>
Hi! I'm currently playing with an optimization for certain GL/Vulkan clients that would replace a surfaces buffer with a single_pixel one. The intention is to let the compositor know that a surface is e.g. completely black (even though the next frame could be a GL/Vulkan one again), so they can skip a hardware plane in KMS.
<robert_mader>
My question now is: if I replace the surface buffer *after* GL/VK commited their (also completely black) buffer - can anyone of you think of negative side-effects? From my understanding, all what would happen is: the compositor releases the GL/VK buffer earlier than otherwise - and the presentation info would be off. Apart from that - are there any assumptions in the Mesa EGL/VK platforms assuming that no other buffer may e
<robert_mader>
hed to a surface "owned" by EGL/Vulkan?
<robert_mader>
p.s.: the use-case is when there's a subsurface with e.g. YUV content on top of the surface used/owned by EGL/VK
<emersion>
i think ideally you'd completely skip GL/Vulkan in that case and won't bother to render at all
<emersion>
the problem with "replacing" is that it's not atomic
<emersion>
vulkan renders + commits a buffer, then you attach another buffer and commit again
<emersion>
i suppose it's not a super big deal if the buffers are identical…
<emersion>
but it's a bit weird
mart has quit [Quit: Konversation terminated!]
<emersion>
(the compositor might process the first commit, then wait an indefinite amount of time, then process the second commit)
<emersion>
(potentially blocking the first commit on a GPU fence)
<robert_mader>
The idea is to keep using the surface you usually use for rendering - e.g. the GTKs main surface - without having the extra-complexity of another subsurface.
junaid has quit [Quit: Lost terminal]
<emersion>
right but you can attach+commit without calling vulkan?
<emersion>
on the same surface used by vulkan
<robert_mader>
Why not?
<robert_mader>
As long as I have a pointer to the wl_surface - I can attach buffers.
<emersion>
sorry, not sure i'm following :P
<emersion>
yes
<emersion>
what i mean is that… currently you do eglSwapBuffers() and then wl_surface_attach()+wl_surface_commit(), right?
<robert_mader>
right
<emersion>
why not skip the eglSwapBuffers()?
<robert_mader>
Mainly to keep things like buffer-age etc in tact.
<emersion>
since it's the same buffer contents conceptually, i think it doesn't matter?
<robert_mader>
Or generally to not touch anything on the renderer side - but to keep things as a backend-level optimization.
Fxzxmic has quit [Remote host closed the connection]
Fxzxmic has joined #wayland
<robert_mader>
The main idea was to not change the EGL/Vulkan flow - but just do something behind their back. The overhead from the additional commit shouldn't matter here, as it only happens once when e.g. entering fullscreen while playing a video or so.
<emersion>
right, so the behind-the-back thing is not something do every frame, but rather once in a blue moon
<emersion>
i think it's fine, but not 100% perfect ;)
<emersion>
in general having extraneous wl_surface.commit in-between is a red flag
<emersion>
but shouldn't matter very much here
<robert_mader>
Well, we already do that in Firefox...
<emersion>
oh please don't tell me about firefox 😭
<robert_mader>
Well, and generally EGL/Vulkan have to live with all kind of other surface state changes without a buffer swap.
<robert_mader>
MrCooper: thanks! Even though from a short look it's not obvious to me that it would be problematic - at least for the use-case in mind.
<emersion>
robert_mader: if FIFO is used, one vblank will show the GL buffer, and the next vblank will show the single-pixel one
Brainium has quit [Ping timeout: 480 seconds]
<emersion>
in general, if you want to transition to something else, it'll have extra latency
<robert_mader>
Ah I see - yeah, that'd be unfortunate.
<emersion>
i think the conclusion is that if you can guarantee that the codepath is only ever triggered for the use-case you describe, it's probably fine
<emersion>
but if it's a more generic thing, it'll probably cause issues sooner or later
Brainium has joined #wayland
<kennylevinsen>
robert_mader: at least for the vsyncsource thing, my old dream was to replace it with a "FrameSource" that cooperated a bit more with rendering to avoid its own commits
<robert_mader>
kennylevinsen: Yeah, I remember...just so much work and little support/interest from Moz people :/
<kennylevinsen>
indeed, and each such task is quite a huge project...
<kennylevinsen>
robert_mader: btw, there's still no plans to move away from gtk3 or avoid using gtk's toplevel handling right?
<robert_mader>
No, AFAIK not. Even though the use of GTK features slowly continues to drop, making a new Wayland only backend more and more realistic IMO.
tzimmermann has quit [Quit: Leaving]
<kennylevinsen>
I recently had a small compositor multi-output bug where window on a 4k monitor ended up being 2x scale (8k). Everything worked fine so I hardly noticed... Until focus changed to/from Firefox, and my poor aging ultrabook had to import 8k shm buffers as Gtk was rendering its focus change animation to the top level underneath, making the whole system freeze for an ungodly amount of time. :P
<kennylevinsen>
A pure Wayland backend would be *awesome*
<robert_mader>
kennylevinsen: FWIW: on Android they just query the maximum refresh rate of the display and use a software timer. I was thinking about doing the same, now that there's the "suspended" toplevel state. That would probably also make things easier with VVR and generally reduce CPU overhead. At the price of slightly worse frame timing.
<kennylevinsen>
We originally had some primitive fixed timer, IIRC it had pretty bad frame jitter - but maybe it could be done better, it's many years ago
cmichael has quit [Quit: Leaving]
<robert_mader>
IIRC the main issue was that it didn't match the screen refresh rate. You can still set it via `widget.wayland.vsync.enabled` and `layout.frame_rate` (unfortunately the later is integer only).
Fxzxmic has quit [Quit: Konversation exit!]
<kennylevinsen>
That could very well be, doesn't hurt to try
Guest3113 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest3180
robert_mader has quit [Quit: Leaving.]
mart has joined #wayland
klaasvakie has joined #wayland
klaasvakie has quit []
rasterman has joined #wayland
feaneron_ has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
feaneron_ is now known as feaneron
leon-anavi has quit [Quit: Leaving]
Narrat has joined #wayland
d42 has joined #wayland
mvlad has quit [Remote host closed the connection]
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
garnacho has quit [Quit: garnacho]
garnacho has joined #wayland
rv1sr has quit []
rasterman has quit [Quit: Gettin' stinky!]
sima has quit [Ping timeout: 480 seconds]
__nick__ has joined #wayland
___nick___ has quit [Ping timeout: 480 seconds]
garnacho has quit [Quit: garnacho]
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
Narrat has quit []
privacy has quit [Remote host closed the connection]