08:57 wlb: weston Merge request !1609 opened by () build: bump to version 14.0.0 for the official release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1609
09:04 wlb: weston Merge request !1609 merged \o/ (build: bump to version 14.0.0 for the official release https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1609)
09:04 wlb: weston/main: Marius Vlad * build: bump to version 14.0.0 for the official release https://gitlab.freedesktop.org/wayland/weston/commit/60981998b252 meson.build
09:05 wlb: weston New tag: 14.0.0 https://gitlab.freedesktop.org/wayland/weston/tags/14.0.0
09:11 wlb: weston Marius Vlad pushed a new branch 14.0 https://gitlab.freedesktop.org/wayland/weston/tree/14.0
09:14 wlb: weston Merge request !1610 opened by () meson.build: reopen main for regular development https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1610
09:22 wlb: weston Merge request !1610 merged \o/ (meson.build: reopen main for regular development https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1610)
09:22 wlb: weston/main: Marius Vlad * meson.build: reopen main for regular development https://gitlab.freedesktop.org/wayland/weston/commit/e026fd654015 meson.build
09:22 wlb: wayland.freedesktop.org Merge request !90 opened by () releases: add weston 14.0.0 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/90
09:23 wlb: wayland.freedesktop.org/main: Marius Vlad * releases: add weston 14.0.0 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/61bad3783f96 releases.html
09:23 wlb: wayland.freedesktop.org Merge request !90 merged \o/ (releases: add weston 14.0.0 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/90)
10:55 Eighth_Doctor: Woot, weston 14 :)
11:00 Eighth_Doctor: mvlad, daniels: weston 14 is on its way to fedora 41: https://bodhi.fedoraproject.org/updates/FEDORA-2024-097ca3fa8e
11:44 daniels: \o/ thanks!
11:57 staceee: hey folks o/ is there a way for a layer shell surface to ask the compositor to "teleport" the pointer to our surface?
11:57 staceee: typical use case is bemenu openning
11:58 kennylevinsen: no, but you can force keyboard focus (keyboard interactivity)
11:59 kennylevinsen: that usually gives you what you need without a disorienting pointer warp
11:59 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
12:00 kennylevinsen: You can "grab" the pointer by extending your surface to cover the whole output
12:00 kennylevinsen: taking pointer focus away from what is beneath
12:00 kennylevinsen: not sure what bemenu would use that for
12:00 staceee: right that the work-arround I had in mind. Let's say it is impossible for now
12:01 kennylevinsen: fine by me ;)
12:01 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?
12:01 staceee: the why would be to improve mouse support, highlight entries with a relative movement
12:02 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
12:02 staceee: pq: another clue I had in mind, but for what I know, layer shell doesn't allow this
12:02 pq: okay
12:02 staceee: right but that would mean a too big change for bemenu, that support multiple backend
12:03 kennylevinsen: it also wouldn't help the user make selections - the pointer is still e.g. in the middle of the screen
12:03 kennylevinsen: with bemenu being at the top or wherever
12:03 kennylevinsen: bemenu would see the pointer, but doesn't make sense that it would interact with a menu unless the pointer was up there
12:04 staceee: it is also harder to predict the entry position. I'm not very fan of this behavior
12:04 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?
12:04 staceee: the user should just place their mouse at the bemenu pop position I guess
12:04 kennylevinsen: yah layer shell supports xdg-popup
12:05 staceee: a transparent popup taking the whole screen?
12:05 staceee: but position would be relative to the popup
12:05 pq: no, not transparent and not whole screen
12:06 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
12:06 pq: *menu entry
12:07 staceee: okok
12:07 pq: I just don't know if relative-pointer and confinement cooperate with xdg-popup
12:08 staceee: what is relative-pointer? what is this protocol?
12:09 kennylevinsen: https://wayland.app/protocols/relative-pointer-unstable-v1
12:09 kennylevinsen: it's basically for games where you do not care about absolute pointer position, but only movement rates
12:10 staceee: does the compositor then hide the pointer icon?
12:11 staceee: this could actually works, with or without popup no?
12:11 kennylevinsen: you still need to acquire pointer focus first
12:11 kennylevinsen: e.g., fullscreen surface
12:12 kennylevinsen: or as pq suggests, trying an input grabbing popup - i imagine that would get rejected though
12:12 staceee: mh
12:12 pq: depends on the pointer focus - is the pointer focus not on the layer-shell surface when the menu is triggered?
12:34 staceee: thanks you guys for the clues ~
12:39 ifreund: input grabbing popups are supposed to have a vaild input event serial in order to grab focus
12:40 ifreund: that is, without an actual pointer button event serial grabbing pointer input with a popup should fail
12:42 zamundaaa[m]: <pq> "Would it be possible to design..." <- FWIW in Plasma we have a clipboard manager thing that works like that
12:42 ifreund: assuming I understand things correctly, I think pointer constraints/relative pointer/a fullscreen transparent surface would do what you want
12:42 zamundaaa[m]: Adding a standardized layer shell request to place the surface under the pointer would probably make sense
12:42 ifreund: whether or not this idea is actually good UX or not is probably a matter of preference :D
12:54 kennylevinsen: Maybe a new anchor
12:54 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.
12:55 pq: *landed changes
12:57 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.
13:11 soreau: they're all just fragments anyway
13:11 soreau: pq: wb
13:12 pq: ty
13:13 pq: I'm back only for 2 days per week though, Mondays and a random other day.
13:13 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
13:14 zamundaaa[m]: https://gitlab.freedesktop.org/swick/wayland-protocols/-/merge_requests/51 and https://gitlab.freedesktop.org/swick/wayland-protocols/-/merge_requests/78
13:15 pq: Cool! I'll try to get to them next week.
13:17 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.
13:18 pq: But maybe default luminance defined by the TF is enough.
13:18 pq: hmm...
13:19 pq: reference white = 80 cd/m², but what would primary color volume maximum be?
13:21 pq: integer encodings of scRGB have a maximum, but floating-point encodings do not have a computationally reasonable maximum.
13:22 mclasen: how do integer encodings of scrgb work?
13:23 pq: I think it was some kind of fixed-point essentially.
13:24 zamundaaa[m]: From Wikipedia: 16 bit integer scRGB uses the "8192x + 4096" equation to convert from float to integer
13:24 mclasen: is that worth supporting?
13:24 zamundaaa[m]: so it only has a range of [-0.5; 7.5[
13:24 pq: mclasen, I don't think so
13:25 pq: it would need a new pixel format
13:25 zamundaaa[m]: mclasen: I don't think it's actually used by anything
13:25 zamundaaa[m]: but if someone wanted to use it, you could just use set_luminances to set the appropriate values for the transfer function
13:27 pq: I don't think we have any signed integer pixel formats.
13:27 zamundaaa[m]: hmm, or not. set_luminances only supports positive values
13:27 zamundaaa[m]: pq: it's not signed
13:27 zamundaaa[m]: The equation "8192x + 4096" converts from an input range of [-0.5; 7.5[ to a 16 bit unorm encoding
13:28 pq: all integer pixel formats are unsigned and normalized to [0.0, 1.0], so they cannot express negative or > 1.0 values.
13:28 pq: in drm_fourcc.h, AFAIK
13:29 zamundaaa[m]: yes, but the value you calculate with this isn't the unorm [0, 1] range but the actual encoding in the buffer
13:30 mclasen: but if gl doesn't have such pixel formats...
13:30 pq: you could say it's part of a special TF, and then it would apply to all bit depths
13:31 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 :)
13:31 pq: yeah
17:13 wlb: wayland Merge request !423 opened by () Draft: Atomic request sequences https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/423
19:33 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
19:33 Muzer: y default for some reason. Is there a go-to, preferably drop-in, replacement for xmodmap?
20:23 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
20:23 kennylevinsen: xmod
20:23 kennylevinsen: xmodmap is an ancient hack
20:24 kennylevinsen: It predates XKB within X11 itself, and hasn’t been carried over.
20:28 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 ;)
20:30 Muzer: (in that genre, see ifconfig vs ip)
20:50 kennylevinsen: Muzer: well, to be fair people have had like 30 years to transition to xkb ;)
20:50 mclasen: now, xkb is the old hack that we stuck to, unfortunately :(
20:51 kennylevinsen: true :/
21:03 bl4ckb0ne: wkb when
21:33 kennylevinsen: It’s just a u256 bitmask of held physical buttons with the description: “good luck”
22:15 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?
22:15 Muzer: if this also isn't wayland's job then apologies! Got to adjust my mental model I guess...
22:17 Muzer: (it's not just xclip either - crucially when I type "*p or "+p in vim I get told the register is empty)(
22:17 kennylevinsen: Muzer: look at wl-clipboard
22:19 Muzer: I found that, and it's useful that there's a native clipboard command line tool, but that won't help vim here.
22:20 Muzer: and is there any reason xclip shouldn't work?
22:20 kennylevinsen: depends, vim might be calling xclip and wl-clipboard has a wrapper IIRC
22:21 kennylevinsen: however, I believe modern terminal emulators provide a clipboard access extension? I forget the details
22:21 kennylevinsen: requires vim/neovim configured appropriately
22:22 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
22:22 Muzer: I've got X support compiled into my vim so I don't think it'll be calling xclip.
22:23 Muzer: oh. I don't care about security, so is there a way to disable that?
22:25 mclasen: no