ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<wargreen>
Hi here
<wargreen>
is it possible , with xwayland, that a window that normaly have Program supplied maximum size, sometime have not this ?
Brainium has quit [Quit: Konversation terminated!]
cool110_ has quit [Remote host closed the connection]
cool110 has joined #wayland
<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?
<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.
wargreen has quit [Ping timeout: 480 seconds]
dcz_ has joined #wayland
sima has joined #wayland
Company has quit [Quit: Leaving]
tzimmermann has joined #wayland
MadcapJake has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
iomari891 has joined #wayland
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
<davidre>
if it's pressed while you have focus you get also a key event
pochu has joined #wayland
yar has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
yar has joined #wayland
MajorBiscuit has joined #wayland
MajorBiscuit has quit []
robobub_ has quit []
<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?
<kchibisov>
more about key state.
<pq>
do you not get the l_shift or r_shift keys in the pressed array of wl_keyboard.enter?
<kchibisov>
I get them, but can I assume that they are actually modifiers?
<pq>
I don't think so.
<kchibisov>
That's what I think as well.
<pq>
but you said you are interested about key state, not modifiers?
<kchibisov>
I'm interested in which shift modifier in particual (lshift/rshift) is pressed.
<pq>
I thought there is only one shift modifier.
<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.
<pq>
lshift and rshift are keys, and shift is a modifier, right?
<kchibisov>
Other platforms have, like macOS, forward which modifier exactly, so clients can have special behavior based on left or right Alt.
<pq>
modifiers are not keys AFAIU
<kchibisov>
Yeah, that's my understanding as well, it's just some platforms forward a key which resulted in modifiers change.
<pq>
oh, so you want to know which key was responsible for the modifier you received?
<kchibisov>
Yes.
fmuellner has joined #wayland
<kchibisov>
But I'm fine with 'such information is not available'.
<kchibisov>
less code to write...
<pq>
there might be no keys down for a given modifier, and it's not explicitly communicated...
<pq>
maybe you could ask the keymap someehow if any of the pressed keys relate to a specific modifier, but I'm not sure
<kchibisov>
I tried to find in the docs, but libxkbcommon docs are a bit obscure.
<kchibisov>
So that's why I've asked ¯\_(ツ)_/¯
<pq>
at least you can ask in maybe a clearer way now :-)
<kchibisov>
I just remembered that physical modifier key might not be responsible for the modifier change.
<kchibisov>
So I wasn't even sure how to ask it.
<kchibisov>
But yeah, what I want is to know the keysym resulted in modifiers change.
<pq>
daniels, xkbcommon.org says you are still maintaining xkbcommon - are you? :-)
<kchibisov>
So I can iterate the keysyms resulting in modifiers change and identify e.g. left/right alt myself.
<daniels>
kchibisov: errr yeah, we both have AltGr and also client-side Compose handling
<daniels>
that's a detail I didn't know of, thanks for filling me in
<kchibisov>
Yeah, and on macOS they also have client side, but they don't have AltGr.
<kchibisov>
it's just Alt.
<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
<kchibisov>
However they have modifiers like event, which is a bitflag with all the mods + positions.
<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
<kchibisov>
So you sort of build what you want yourself.
<kchibisov>
Yeah, but with libxkb you have options like define your own keymap.
<kchibisov>
which you don't on macOS.
<kchibisov>
So I think all of that is not required, because you can redifine whatever you want on a system level.
<kchibisov>
And don't have to write 'modifiers remapping in every library/application', like you have on macOS.
<kchibisov>
note, that macOS has general remapping, but not for the behavior of Alt/Option.
dnk has joined #wayland
neonking has quit [Remote host closed the connection]
neonking has joined #wayland
Leopold_ has quit [Remote host closed the connection]
wargreen has joined #wayland
Leopold_ has joined #wayland
nerdopolis has joined #wayland
jess has quit []
Company has joined #wayland
<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")?
<emersion>
zzag: yes
<emersion>
zzag: specifically, you need to drmCloseBufferHandle() only once when both users of the handle are done with it
<zzag>
thanks
<emersion>
what i do in wlroots: drmPrimeFDToHandle(), then AddFB2(), then close handles immediately
<emersion>
on a DRM FD not shared with anyone else
<emersion>
you also need to be careful about DMA-BUFs with the same handle for multiple planes
<zzag>
how do you get one?
<zzag>
I mean DRM FD
<emersion>
there are two ways
<emersion>
one is create a DRM lease with no resources on it
<emersion>
only possible with recent-ish kernels
<emersion>
the other is to re-open the card device
<emersion>
only possible when the user is physically logged in and udev changed the permissions of the card
<emersion>
see reopen_drm_node() in wlroots
<zzag>
emersion: oh, cool. thanks!
<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
<zzag>
thank you for your help
<pq>
weston mainly uses GBM to avoid calling ToHandle itself, not sure what the create_recorder thing is doing
* zzag
wishes drmPrimeFDToHandle() didn't have this pesky refcounting pitfall
* emersion
whishes as well
<pq>
maybe vaapi does not use GBM import machinery, so would get confused with handles without the separate DRM device fd?
<pq>
if so, what a fine trap
<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
wargreen has quit [Ping timeout: 480 seconds]
<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.)
ufk has joined #wayland
<ufk>
hi, does wayland supports nvidia-drivers ?
<kennylevinsen>
"wayland" is a protocol specification. Check with your Wayland server/compositor of choice (e.g., GNOME/Mutter, KDE/kwin, sway, weston, ...)
<ufk>
oh thanks
<ufk>
i use mutter
<kennylevinsen>
Then the answer is most likely yes, but for more information ask in a GNOME support channel. :)
<ufk>
thank you
<daniels>
maybe an AddFB2 flag which allows you to pass FDs instead of handles?
<DodoGTA>
Where is the region of a wl_surface specified in the WAYLAND_DEBUG logs?
<jadahl>
DodoGTA: you mean opaque region, or input reagion? both are defined with wl_region and set with wl_surface.set_[input|opaque]_region
<DodoGTA>
jadahl: I meant input region (set_input_region doesn't appear anywhere though)
___nick___ has joined #wayland
___nick___ has quit []
Szadek has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
<DodoGTA>
Does that mean the lock_pointer() call has no real effect (other than hiding the pointer)?
___nick___ has joined #wayland
<jadahl>
DodoGTA: not setting an input region should mean "infinite" i.e. covering the whole surface
<DodoGTA>
Which doesn't work well with relative pointer input and multiple monitors
<jadahl>
why?
<kennylevinsen>
DodoGTA: how would constraining a pointer inside a surface and getting relative pointer input have anything to do with multiple monitors?
<DodoGTA>
I mean the pointer escapes out of the fullscreen wl_surface in one of my monitors which causes relative input to stop working
<jadahl>
DodoGTA: assuming you actually got the pointer lock/constraint, then something to report to the compositor you're using
floof58 has quit [Remote host closed the connection]
floof58 has joined #wayland
sima has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
<DodoGTA>
Xonotic/SDL2 only calls set_opaque_region() and interestingly the pointer is locked and confined correctly there
mvlad has quit [Quit: Leaving]
floof58 has quit [Read error: Connection reset by peer]
floof58 has joined #wayland
<jadahl>
DodoGTA: that means the input region is "infinite" which in practice means "identical to the surface region itself"
___nick___ has quit [Ping timeout: 480 seconds]
<kennylevinsen>
opaque region has nothing to do with input, region objects are used for multiple things in the protocols :)