ChanServ changed the topic of #wayland to: | 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 ?
<wargreen> (and all work well when it isn't)
<wargreen> s/well/better/
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
<wlb> weston Issue #755 closed \o/ ([weston 11.0.1] QT button is not released
fmuellner has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
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, 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: modifiers aren't always triggered by a single key - sometimes it's a combination or sequence
<daniels> but yeah, even for the easy single-key ones, no that's not available I'm afraid
<daniels> may I ask what for?
<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
<pq> daniels, forgot to be regenerated?
<kchibisov> I don't think the reason is compelling.
<pq> at the very bottom
<kchibisov> Are you familiar with macOS keyboard input, daniels ?
<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
<daniels> kchibisov: not natively, no - I learned a bit about 15 years ago and have now forgotten it all
<pq> heh
<kchibisov> Basically macOS doesn't have real compose key, so they use both Alts as compose key.
<kchibisov> While this is fine for normal applications, terminal emulators require more traditional alt.
<kchibisov> So terminal emulators have an option on macOS to map macOS's Option key as Alt.
<kchibisov> And to have both at the same time, they could map only Left or Right Option to Alt.
<kchibisov> That's the only real use case for that, but on Linux you don't need any of that hacks.
<kchibisov> Because you have AltGr.
<davidre> At least KWin sends the actual key event. I imagine other compositors using libinput do so as well
<kchibisov> I simply asked because I was extending our windowing library modifiers event to carry (left/right) alt.
<davidre> thisis me pressing left and right shift
<kchibisov> I'm fine with X11/Wayland returning 'None' as position, was mostly curious if it's possible in general.
<davidre> [2852363.596] wl_keyboard@3.key(1313, 7967607, 42, 1)... (full message at <>)
mvlad has joined #wayland
cmichael has joined #wayland
<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? 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?
<emersion> hm yeah that sounds like a good idea
<daniels> I do have those occasionally :P
ufk has quit [Remote host closed the connection]
Leopold_ has quit []
Leopold_ has joined #wayland
alatiera has quit [Ping timeout: 480 seconds]
kh has joined #wayland
kh has quit []
mohit815 has quit [Quit: The Lounge -]
mohit815 has joined #wayland
tzimmermann has quit [Quit: Leaving]
i509vcb has quit [Quit: Connection closed for inactivity]
Fxzxmic has joined #wayland
pochu has quit [Quit: leaving]
Fxzxmic has quit [Quit: Konversation exit!]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
junaid has joined #wayland
cmichael has quit [Quit: Leaving]
junaid has quit [Ping timeout: 480 seconds]
rederick29 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
nerdopolis has joined #wayland
Szadek has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
anarsoul|2 has quit [Quit: ZNC 1.8.2 -]
anarsoul has joined #wayland
<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 :)
dnk has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
alain67 has joined #wayland
alain67 has quit [Quit: - Chat comfortably. Anywhere.]
Leopold_ has quit []
Leopold_ has joined #wayland
rv1sr has quit []
dcz_ has quit [Ping timeout: 480 seconds]
iomari891 has quit [Ping timeout: 480 seconds]
rederick29 has quit [Remote host closed the connection]
bindu has quit [Quit: leaving]
bindu has joined #wayland