ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
fmuellner has quit [Ping timeout: 480 seconds]
RAOF has quit [Remote host closed the connection]
garnacho has joined #wayland
crazybyte has quit [Quit: Bye]
crazybyte has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
RAOF has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
karenw has joined #wayland
Company has quit [Ping timeout: 480 seconds]
Company has joined #wayland
Brainium_ has quit []
kts has joined #wayland
kts has quit []
kts has joined #wayland
mxz__ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
mxz___ has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
mxz___ is now known as mxz
mxz_ has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
psykose has joined #wayland
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
karenw has quit [Ping timeout: 480 seconds]
sima has joined #wayland
crazybyte has quit [Read error: Connection reset by peer]
<staceee>
hey folks o/ is there a way for a layer shell surface to ask the compositor to "teleport" the pointer to our surface?
<staceee>
typical use case is bemenu openning
<kennylevinsen>
no, but you can force keyboard focus (keyboard interactivity)
<kennylevinsen>
that usually gives you what you need without a disorienting pointer warp
<staceee>
that what bemenu does. But someone ask if it could also grab pointer events (event from outside the surface). And I think it is impossible by design
<kennylevinsen>
You can "grab" the pointer by extending your surface to cover the whole output
<kennylevinsen>
taking pointer focus away from what is beneath
<kennylevinsen>
not sure what bemenu would use that for
<staceee>
right that the work-arround I had in mind. Let's say it is impossible for now
<kennylevinsen>
fine by me ;)
<pq>
Would it be possible to design that UI such that the menu opens in a position where the pointer would be readily in the right place wrt. the menu without warping?
<staceee>
the why would be to improve mouse support, highlight entries with a relative movement
<kennylevinsen>
but for reference, slurp (tool for selecting a rect on an output) works by drawing a transparent layer shell surface which you can interact with to draw (non-transparent) rects for selection
<staceee>
pq: another clue I had in mind, but for what I know, layer shell doesn't allow this
<pq>
okay
<staceee>
right but that would mean a too big change for bemenu, that support multiple backend
<kennylevinsen>
it also wouldn't help the user make selections - the pointer is still e.g. in the middle of the screen
<kennylevinsen>
with bemenu being at the top or wherever
<kennylevinsen>
bemenu would see the pointer, but doesn't make sense that it would interact with a menu unless the pointer was up there
<staceee>
it is also harder to predict the entry position. I'm not very fan of this behavior
<pq>
Could one use an xdg-popup on top of the layer-shell surface? That would grab, right? Would it also allow relative-pointer and confinement?
<staceee>
the user should just place their mouse at the bemenu pop position I guess
<staceee>
a transparent popup taking the whole screen?
<staceee>
but position would be relative to the popup
<pq>
no, not transparent and not whole screen
<pq>
with relative-pointer and confinement, you'd essentially hide the normal pointer cursor and instead just drive emny entry selection from relative pointer events - if that's possible
<pq>
*menu entry
<staceee>
okok
<pq>
I just don't know if relative-pointer and confinement cooperate with xdg-popup
rgallaispou has joined #wayland
<staceee>
what is relative-pointer? what is this protocol?
<kennylevinsen>
it's basically for games where you do not care about absolute pointer position, but only movement rates
<staceee>
does the compositor then hide the pointer icon?
<staceee>
this could actually works, with or without popup no?
<kennylevinsen>
you still need to acquire pointer focus first
<kennylevinsen>
e.g., fullscreen surface
rgallaispou has quit [Read error: Connection reset by peer]
<kennylevinsen>
or as pq suggests, trying an input grabbing popup - i imagine that would get rejected though
<staceee>
mh
<pq>
depends on the pointer focus - is the pointer focus not on the layer-shell surface when the menu is triggered?
___nick___ has joined #wayland
rgallaispou has joined #wayland
akallabeth[m] has joined #wayland
<staceee>
thanks you guys for the clues ~
rgallaispou has quit [Read error: Connection reset by peer]
<ifreund>
input grabbing popups are supposed to have a vaild input event serial in order to grab focus
Moprius has joined #wayland
<ifreund>
that is, without an actual pointer button event serial grabbing pointer input with a popup should fail
zamundaaa[m] has joined #wayland
<zamundaaa[m]>
<pq> "Would it be possible to design..." <- FWIW in Plasma we have a clipboard manager thing that works like that
<ifreund>
assuming I understand things correctly, I think pointer constraints/relative pointer/a fullscreen transparent surface would do what you want
<zamundaaa[m]>
Adding a standardized layer shell request to place the surface under the pointer would probably make sense
<ifreund>
whether or not this idea is actually good UX or not is probably a matter of preference :D
cyrinux has quit []
cyrinux has joined #wayland
<kennylevinsen>
Maybe a new anchor
<pq>
I have viewed the changes to color-management protocol since my disappearance 10 weeks ago, and after some pondering, they all look fine to me. Good work.
<pq>
*landed changes
Moprius has quit [Quit: bye]
<pq>
I'm sure the cd/m² numbers will confuse some people to thinking that they are displayed nit-for-nit, but I cannot think of a better way.
TheCaptain82970403198578471379 has quit [Ping timeout: 480 seconds]
gryffus_ has joined #wayland
<soreau>
they're all just fragments anyway
<soreau>
pq: wb
<pq>
ty
<pq>
I'm back only for 2 days per week though, Mondays and a random other day.
gryffus has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
pq: to sum up some discussions from when you were away, there's only two things that we found really should be taken care of before finally merging the protocol
<pq>
The extended linear TF specifically for the scRGB variant with 1.0 = 80 cd/m² is something to think about, it's a little bit conflating two different things.
<pq>
But maybe default luminance defined by the TF is enough.
<pq>
hmm...
<pq>
reference white = 80 cd/m², but what would primary color volume maximum be?
<pq>
integer encodings of scRGB have a maximum, but floating-point encodings do not have a computationally reasonable maximum.
<mclasen>
how do integer encodings of scrgb work?
<pq>
I think it was some kind of fixed-point essentially.
<zamundaaa[m]>
From Wikipedia: 16 bit integer scRGB uses the "8192x + 4096" equation to convert from float to integer
<mclasen>
is that worth supporting?
<zamundaaa[m]>
so it only has a range of [-0.5; 7.5[
<pq>
mclasen, I don't think so
<pq>
it would need a new pixel format
<zamundaaa[m]>
mclasen: I don't think it's actually used by anything
<zamundaaa[m]>
but if someone wanted to use it, you could just use set_luminances to set the appropriate values for the transfer function
<pq>
I don't think we have any signed integer pixel formats.
<zamundaaa[m]>
hmm, or not. set_luminances only supports positive values
<zamundaaa[m]>
pq: it's not signed
<zamundaaa[m]>
The equation "8192x + 4096" converts from an input range of [-0.5; 7.5[ to a 16 bit unorm encoding
<pq>
all integer pixel formats are unsigned and normalized to [0.0, 1.0], so they cannot express negative or > 1.0 values.
<pq>
in drm_fourcc.h, AFAIK
<zamundaaa[m]>
yes, but the value you calculate with this isn't the unorm [0, 1] range but the actual encoding in the buffer
<mclasen>
but if gl doesn't have such pixel formats...
<pq>
you could say it's part of a special TF, and then it would apply to all bit depths
xantoz has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
mclasen: you'd need to do the encoding in a shader anyways. But it all doesn't matter, it's not like anyone wants to actually use integer scRGB :)
<pq>
yeah
nafen has quit [Quit: WeeChat 4.4.1]
Lyude has quit [Quit: Bouncer restarting]
Lyude has joined #wayland
mceier has quit [Quit: leaving]
kts has joined #wayland
mceier has joined #wayland
lyudess has joined #wayland
Lyude has quit [Ping timeout: 480 seconds]
lyudess has quit []
Lyude has joined #wayland
leon-anavi has joined #wayland
llyyr has quit [Quit: Quit]
llyyr has joined #wayland
Company has joined #wayland
rampagequeen has joined #wayland
zamundaaa[m] has quit [Remote host closed the connection]
akallabeth[m] has quit [Remote host closed the connection]
Eighth_Doctor has quit [Remote host closed the connection]
rampagequeen has quit [Remote host closed the connection]
alatiera6 has quit []
vincejv has joined #wayland
aswar002 has quit [Read error: Connection reset by peer]
aswar002 has joined #wayland
aswar002 has quit [Remote host closed the connection]
shankaru has quit [Remote host closed the connection]
aswar002 has joined #wayland
shankaru has joined #wayland
alatiera6 has joined #wayland
AJ_Z0 has quit [Quit: I have to return some videotapes]
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
akallabeth[m] has joined #wayland
cyrinux has quit []
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
tzimmermann has quit [Quit: Leaving]
leon-anavi has quit [Quit: Leaving]
Guest2470 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest2516
psykose has quit [Remote host closed the connection]
alatiera6 has joined #wayland
Muzer has joined #wayland
<Muzer>
Hi all, apologies for the nooby question. Just upgraded my KDE version and decided to try out wayland since it's now the default. First thing I'm missing is my ~/.Xmodmap no longer works — my keyboard contains some very annoying back and forward keys by the cursor keys which are easy to press accidentally and so I like to remap them to XF86ApplicationLeft and XF86ApplicationRight. Also I need a working scroll lock key which at least under X is disabled b
<Muzer>
y default for some reason. Is there a go-to, preferably drop-in, replacement for xmodmap?
lsd|2 has joined #wayland
Moprius has joined #wayland
Brainium has joined #wayland
cyrinux has joined #wayland
cyrinux has quit []
Moprius_ has joined #wayland
Moprius_ has quit []
Moprius has quit [Ping timeout: 480 seconds]
cyrinux has joined #wayland
Brainium has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
Brainium has joined #wayland
___nick___ has quit [Remote host closed the connection]
Moprius has quit []
Brainium has quit []
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #wayland
<kennylevinsen>
Muzer: that’s a KDE question mainly, but you can usually create a custom xkb layout that modifies what you need and includes the rest
<kennylevinsen>
xmod
<kennylevinsen>
xmodmap is an ancient hack
<kennylevinsen>
It predates XKB within X11 itself, and hasn’t been carried over.
rv1sr has quit []
<Muzer>
Thanks! I'll try and give it a go with xkb. Having just fiddled with xkb for a little bit it definitely feels like one of those cases where people stuck with the ancient hack because it was much easier to work with than the nice way ;)
<Muzer>
(in that genre, see ifconfig vs ip)
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #wayland
sima has quit [Ping timeout: 480 seconds]
<kennylevinsen>
Muzer: well, to be fair people have had like 30 years to transition to xkb ;)
<mclasen>
now, xkb is the old hack that we stuck to, unfortunately :(
<kennylevinsen>
true :/
<bl4ckb0ne>
wkb when
kelnos has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
kelnos has joined #wayland
<kennylevinsen>
It’s just a u256 bitmask of held physical buttons with the description: “good luck”
Guest2516 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest2530
Brainium has joined #wayland
<Muzer>
Managed to get my keyboard mapping working (at least for the back/forwards keys, might have to figure out scroll lock later). Next problem: maybe this is expected but X11 clipboard integration seems to be not working for me. When I run `xclip -o` I get `Error: target STRING not available`. Any ideas?
<Muzer>
if this also isn't wayland's job then apologies! Got to adjust my mental model I guess...
<Muzer>
(it's not just xclip either - crucially when I type "*p or "+p in vim I get told the register is empty)(
<kennylevinsen>
Muzer: look at wl-clipboard
<Muzer>
I found that, and it's useful that there's a native clipboard command line tool, but that won't help vim here.
<Muzer>
and is there any reason xclip shouldn't work?
<kennylevinsen>
depends, vim might be calling xclip and wl-clipboard has a wrapper IIRC
<kennylevinsen>
however, I believe modern terminal emulators provide a clipboard access extension? I forget the details
<kennylevinsen>
Muzer: yes, in wayland a window only gets access to clipboard content if it has focus, and Xwayland basically looks like a single wayland app with a bunch of windows - none of them is in focus when you call xclip
<Muzer>
I've got X support compiled into my vim so I don't think it'll be calling xclip.
<Muzer>
oh. I don't care about security, so is there a way to disable that?
<mclasen>
no
feaneron has quit [Quit: feaneron]
mvlad has quit [Remote host closed the connection]
mvlad has joined #wayland
Lucretia-backup has quit []
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
mclasen has quit [Remote host closed the connection]
mclasen has joined #wayland
mvlad has quit [Remote host closed the connection]