00:10 wargreen: Hi here
00:11 wargreen: is it possible , with xwayland, that a window that normaly have Program supplied maximum size, sometime have not this ?
00:11 wargreen: (and all work well when it isn't)
00:11 wargreen: s/well/better/
01:44 wlb: weston Issue #755 closed \o/ ([weston 11.0.1] QT button is not released https://gitlab.freedesktop.org/wayland/weston/-/issues/755)
04:37 kchibisov: Is it correct that having 'Left Shift' pressed doesn't mean that you have Shift modifier, so you can't destinguish l_shift from r_shift, etc?
04:39 kchibisov: In general I wonder whether there's a reliable way of providing more info in client side library when you get `wl_keyboard::modifiers`, as in when you get `shift` tell which shift (left or right), and the same with `alt`, etc.
06:45 davidre: if it's pressed while you have focus you get also a key event
08:36 pq: kchibisov, are you thinking that keymaps have separate shift level modifiers for left and right shift? or is this specifically abouy key state and not about modifiers wrt. keymap?
08:37 kchibisov: more about key state.
08:38 pq: do you not get the l_shift or r_shift keys in the pressed array of wl_keyboard.enter?
08:38 kchibisov: I get them, but can I assume that they are actually modifiers?
08:38 pq: I don't think so.
08:38 kchibisov: That's what I think as well.
08:38 pq: but you said you are interested about key state, not modifiers?
08:39 kchibisov: I'm interested in which shift modifier in particual (lshift/rshift) is pressed.
08:39 pq: I thought there is only one shift modifier.
08:39 kchibisov: So if I've got modifiers event saying that I have shift pressed, I want to know whether it's part due to lshift or rshift.
08:40 pq: lshift and rshift are keys, and shift is a modifier, right?
08:40 kchibisov: Other platforms have, like macOS, forward which modifier exactly, so clients can have special behavior based on left or right Alt.
08:40 pq: modifiers are not keys AFAIU
08:41 kchibisov: Yeah, that's my understanding as well, it's just some platforms forward a key which resulted in modifiers change.
08:41 pq: oh, so you want to know which key was responsible for the modifier you received?
08:41 kchibisov: Yes.
08:41 kchibisov: But I'm fine with 'such information is not available'.
08:42 kchibisov: less code to write...
08:42 pq: there might be no keys down for a given modifier, and it's not explicitly communicated...
08:43 pq: maybe you could ask the keymap someehow if any of the pressed keys relate to a specific modifier, but I'm not sure
08:43 kchibisov: I tried to find in the docs, but libxkbcommon docs are a bit obscure.
08:43 kchibisov: So that's why I've asked ¯\_(ツ)_/¯
08:46 pq: at least you can ask in maybe a clearer way now :-)
08:47 kchibisov: I just remembered that physical modifier key might not be responsible for the modifier change.
08:48 kchibisov: So I wasn't even sure how to ask it.
08:48 kchibisov: But yeah, what I want is to know the keysym resulted in modifiers change.
08:48 pq: daniels, xkbcommon.org says you are still maintaining xkbcommon - are you? :-)
08:49 kchibisov: So I can iterate the keysyms resulting in modifiers change and identify e.g. left/right alt myself.
08:50 daniels: pq: https://github.com/xkbcommon/website/pull/3
08:51 daniels: kchibisov: modifiers aren't always triggered by a single key - sometimes it's a combination or sequence
08:51 daniels: but yeah, even for the easy single-key ones, no that's not available I'm afraid
08:51 daniels: may I ask what for?
08:51 daniels: we'd need to bump wl_keyboard as well as xkbcommon api to add it but if there's a compelling reason then it could be done
08:52 pq: daniels, https://xkbcommon.org/ forgot to be regenerated?
08:52 kchibisov: I don't think the reason is compelling.
08:52 pq: at the very bottom
08:52 kchibisov: Are you familiar with macOS keyboard input, daniels ?
08:52 daniels: pq: yeah, there's an issue somewhere about making it be autogenerated rather than requiring Ran to scp stuff to my Linode machine :P
08:52 daniels: kchibisov: not natively, no - I learned a bit about 15 years ago and have now forgotten it all
08:52 pq: heh
08:53 kchibisov: Basically macOS doesn't have real compose key, so they use both Alts as compose key.
08:53 kchibisov: While this is fine for normal applications, terminal emulators require more traditional alt.
08:54 kchibisov: So terminal emulators have an option on macOS to map macOS's Option key as Alt.
08:54 kchibisov: And to have both at the same time, they could map only Left or Right Option to Alt.
08:54 kchibisov: That's the only real use case for that, but on Linux you don't need any of that hacks.
08:54 kchibisov: Because you have AltGr.
08:55 davidre: At least KWin sends the actual key event. I imagine other compositors using libinput do so as well
08:55 kchibisov: I simply asked because I was extending our windowing library modifiers event to carry (left/right) alt.
08:56 davidre: thisis me pressing left and right shift
08:56 kchibisov: I'm fine with X11/Wayland returning 'None' as position, was mostly curious if it's possible in general.
08:56 davidre: [2852363.596] wl_keyboard@3.key(1313, 7967607, 42, 1)... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/TRsTqwApmsCiOBCJilpQGebk>)
09:29 daniels: kchibisov: errr yeah, we both have AltGr and also client-side Compose handling
09:29 daniels: that's a detail I didn't know of, thanks for filling me in
09:29 kchibisov: Yeah, and on macOS they also have client side, but they don't have AltGr.
09:29 kchibisov: it's just Alt.
09:29 daniels: so there is an issue somewhere about having proper support for virtual modifiers, which are purely informational and do not affect the state in the same way that real modifiers do
09:30 kchibisov: However they have modifiers like event, which is a bitflag with all the mods + positions.
09:30 daniels: e.g. Alt would be composed of LAlt + RAlt vmods, so most people could query for Alt (ok, Mod4) being active since that's the thing they care about, but people who really had opinions about it could query for LAlt/RAlt to find out which one it was, then get flamed to death by left-handers
09:30 kchibisov: So you sort of build what you want yourself.
09:31 kchibisov: Yeah, but with libxkb you have options like define your own keymap.
09:31 kchibisov: which you don't on macOS.
09:31 kchibisov: So I think all of that is not required, because you can redifine whatever you want on a system level.
09:32 kchibisov: And don't have to write 'modifiers remapping in every library/application', like you have on macOS.
09:32 kchibisov: note, that macOS has general remapping, but not for the behavior of Alt/Option.
12:34 zzag: emersion: do I understand drmPrimeFDToHandle()/drmPrimeHandleToFD() documentation correctly? https://invent.kde.org/-/snippets/2676 Is "DRM file description" the fd returned by open("/dev/dri/cardN" or "/dev/dri/renderDN")?
12:36 emersion: zzag: yes
12:36 emersion: zzag: specifically, you need to drmCloseBufferHandle() only once when both users of the handle are done with it
12:38 zzag: thanks
12:38 emersion: what i do in wlroots: drmPrimeFDToHandle(), then AddFB2(), then close handles immediately
12:38 emersion: on a DRM FD not shared with anyone else
12:39 emersion: you also need to be careful about DMA-BUFs with the same handle for multiple planes
12:39 zzag: how do you get one?
12:39 zzag: I mean DRM FD
12:39 emersion: there are two ways
12:39 emersion: one is create a DRM lease with no resources on it
12:39 emersion: only possible with recent-ish kernels
12:40 emersion: the other is to re-open the card device
12:40 emersion: only possible when the user is physically logged in and udev changed the permissions of the card
12:41 emersion: see reopen_drm_node() in wlroots
12:41 zzag: emersion: oh, cool. thanks!
12:44 zzag: okay, so wlroots open()s the drm node and takes care of authentication. weston seems to do similar in create_recorder() in libweston/backend-drm/drm.c
12:44 zzag: thank you for your help
12:46 pq: weston mainly uses GBM to avoid calling ToHandle itself, not sure what the create_recorder thing is doing
12:46 zzag:wishes drmPrimeFDToHandle() didn't have this pesky refcounting pitfall
12:46 emersion:whishes as well
12:47 pq: maybe vaapi does not use GBM import machinery, so would get confused with handles without the separate DRM device fd?
12:49 pq: if so, what a fine trap
12:59 MrCooper: zzag: technically, a file descriptor is a reference to a file description; multiple file descriptors (even in separate processes) can reference the same description, e.g. via dup
13:04 kennylevinsen: (That's how seatd and logind works - they open drm and evdev devices and send a file descriptor over a UNIX domain socket. By holding an fd to the same file description themselves, they can revoke evdev and drm rights afterwards.)
13:27 ufk: hi, does wayland supports nvidia-drivers ?
13:28 kennylevinsen: "wayland" is a protocol specification. Check with your Wayland server/compositor of choice (e.g., GNOME/Mutter, KDE/kwin, sway, weston, ...)
13:28 ufk: oh thanks
13:28 ufk: i use mutter
13:29 kennylevinsen: Then the answer is most likely yes, but for more information ask in a GNOME support channel. :)
13:29 ufk: thank you
13:31 daniels: maybe an AddFB2 flag which allows you to pass FDs instead of handles?
13:32 emersion: hm yeah that sounds like a good idea
13:33 daniels: I do have those occasionally :P
19:01 DodoGTA: Where is the region of a wl_surface specified in the WAYLAND_DEBUG logs?
19:02 jadahl: DodoGTA: you mean opaque region, or input reagion? both are defined with wl_region and set with wl_surface.set_[input|opaque]_region
19:03 DodoGTA: jadahl: I meant input region (set_input_region doesn't appear anywhere though)
19:09 DodoGTA: Does that mean the lock_pointer() call has no real effect (other than hiding the pointer)?
19:23 jadahl: DodoGTA: not setting an input region should mean "infinite" i.e. covering the whole surface
19:30 DodoGTA: Which doesn't work well with relative pointer input and multiple monitors
19:32 jadahl: why?
19:37 kennylevinsen: DodoGTA: how would constraining a pointer inside a surface and getting relative pointer input have anything to do with multiple monitors?
19:40 DodoGTA: I mean the pointer escapes out of the fullscreen wl_surface in one of my monitors which causes relative input to stop working
19:42 jadahl: DodoGTA: assuming you actually got the pointer lock/constraint, then something to report to the compositor you're using
20:14 DodoGTA: Xonotic/SDL2 only calls set_opaque_region() and interestingly the pointer is locked and confined correctly there
20:27 jadahl: DodoGTA: that means the input region is "infinite" which in practice means "identical to the surface region itself"
20:30 kennylevinsen: opaque region has nothing to do with input, region objects are used for multiple things in the protocols :)