02:57orowith2os[m]: I wonder if it's possible to have more than one xdg_popup per wl_surface
02:57orowith2os[m]: not in a chain, but a wl_surface actually has two separate xdg_popups, both active
04:01danieldg: orowith2os[m]: consider multi-seat, with two cursors over two elements both getting a tooltip popup. Or, both touch and mouse interactions generating popups.
04:02orowith2os[m]: I'm guessing that's a yes, then
04:02danieldg: I'd check to see if you can make it happen on existing compositors too
06:53YaLTeR[m]: Firefox can show a tooltip while a popup is open, but in that case the tooltip will use a subsurface for some reason
06:53YaLTeR[m]: GTK can show a tooltip while a popup is open I think
06:54YaLTeR[m]: at least if the compositor lets the pointer enter the parent surface during a popup grab
09:03wlb: wayland.freedesktop.org/main: José Expósito * libinput 1.25.0 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/0c904e93ed0f libinput/doc/ 1.25.0/.buildinfo 1.25.0/_images/button-debouncing-wave-diagram.svg 1.25.0/_images/button-scrolling.svg 1.25.0/_images/clickfinger-distance.svg 1.25.0/_images/clickfinger.svg 1.25.0/_images/edge-scrolling.svg 1.25.0/_images/gesture-2fg-ambigu
09:50wlb: wayland.freedesktop.org Issue #6 opened by José Expósito (JoseExposito) CI: zlib signature error https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/issues/6
10:21wlb: wayland.freedesktop.org Merge request !74 opened by José Expósito (JoseExposito) ci: use Alpine Linux instead of Arch as base image https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/74
10:39wlb: weston Issue #865 opened by Neal Gompa (ニール・ゴンパ) (Conan_Kudo) Add support for listening and reconfiguring the keyboard layout from locale1 https://gitlab.freedesktop.org/wayland/weston/-/issues/865
10:59wlb: wayland.freedesktop.org Issue #6 closed \o/ (CI: zlib signature error https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/issues/6)
10:59wlb: wayland.freedesktop.org Issue #6 closed \o/ (CI: zlib signature error https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/issues/6)
10:59wlb: wayland.freedesktop.org/main: José Expósito * ci: use Alpine Linux instead of Arch as base image https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/3f75884f99eb .gitlab-ci.yml
10:59wlb: wayland.freedesktop.org Merge request !74 merged \o/ (ci: use Alpine Linux instead of Arch as base image https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/74)
11:03wlb: wayland.freedesktop.org Merge request !63 merged \o/ (ci: call meson setup for the libinput build https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/63)
11:03wlb: wayland.freedesktop.org/main: Peter Hutterer * ci: call meson setup for the libinput build https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/89f2ba21c887 .gitlab-ci.yml
11:23Eighth_Doctor: are there any weston folks here?
11:23Eighth_Doctor: I just filed the request for having weston respond to locale1 for keyboard settings, and I was wondering if anyone would be able to take a look into it sooner rather than later
11:24Eighth_Doctor: the context for this is that I'm trying to port Anaconda (the RH/Fedora installer) to run on Weston: https://github.com/rhinstaller/anaconda/pull/5401
11:29pq: Eighth_Doctor, that's interesting. Probably not me personally. What does daniels think?
11:30Eighth_Doctor: Weston was pretty much the only compositor I could find that would match the mix of things that Anaconda did on X11
11:30Eighth_Doctor: notably, having VNC support :)
11:30Eighth_Doctor: and a path to also adding RDP support :D
11:31Eighth_Doctor: also, it's not glitchy as hell as some of the other ones I tried :P
11:31Eighth_Doctor: Weston is now the default compositor for Anaconda's firstboot program too: https://github.com/rhinstaller/initial-setup/pull/149
11:34Eighth_Doctor: pq: the only gaps I've found are related to not having a way to dynamically reconfigure anything in Weston
11:34Eighth_Doctor: outputs, keyboard configuration, input methods, etc.
11:35Eighth_Doctor: there was a patchset 10 years ago that would have also introduced weston-control and a mechanism that could be used for this purpose, but it didn't land: https://lists.freedesktop.org/archives/wayland-devel/2013-April/008542.html
11:35pq: yeah, that might be a lot of work
11:36Eighth_Doctor: for the anaconda case, most of the things I don't need to worry about right now... but responding to locale1 for keyboard configuration would cover the basic needs
11:38pq: I would think that dynamic reconfiguration should also be persistent, and not like xrandr etc making the next start-up a mess.
11:38Eighth_Doctor: yes, ideally it would trigger writing to weston.ini
11:39Eighth_Doctor: but I don't think anything in weston does that
11:39Eighth_Doctor: in that respect, it follows the xserver model in only reading persistent config
11:40Eighth_Doctor: it does, however, lack a weston.ini.d config thing
11:40pq: We barely have NIH'd code to read weston.ini, extending that is probably not the best idea. Personally I'd like to see Weston using some library for this that does it all.
11:40Eighth_Doctor: yeah
11:41pq: You wouldn't happen to have any suggestions for such lib?
11:41Eighth_Doctor: I might actually
11:42Eighth_Doctor: pq: three options I can think of: libeconf, libconfuse, and libconfig
11:43Eighth_Doctor: https://github.com/openSUSE/libeconf
11:43Eighth_Doctor: https://github.com/libconfuse/libconfuse
11:43Eighth_Doctor: https://github.com/hyperrealm/libconfig
11:44Eighth_Doctor: pq: I think libeconf would actually be the best choice for being able to make it easy to support layered configuration in weston
11:45Eighth_Doctor: a number of other projects use it, notably pam does
11:45Eighth_Doctor: oh and util-linux
11:45pq: and dynamic change and write-back support?
11:46Eighth_Doctor: libeconf doesn't do writing config
11:46Eighth_Doctor: only parsing
11:51Eighth_Doctor: pq: for read+write, inih and iniparser are good options
11:51Eighth_Doctor: https://github.com/benhoyt/inih
11:51Eighth_Doctor: https://github.com/ndevilla/iniparser
11:52pq: cool, I'm trying to find the old Weston issue to list these in, I thought there was one...
11:52Eighth_Doctor: I would probably go with inih over iniparser
11:52Eighth_Doctor: since inih more closely matches Weston's existing ini parsing
11:53Eighth_Doctor: though if I'm being honest, if we could, I'd change to TOML instead
11:54pq: I think we could also do something completely different than current weston.ini, if it's attractive enough.
11:54Eighth_Doctor: there are a lot more implementations and it's standardized in a way that ini is not
11:54soreau: pq: that route probably looks a lot like kanshi with weston supporting wlr-output-management protocol
11:55soreau: then you'd get wlr-randr support for free too
11:55pq: maybe that means we need to write a second Weston frontend, but that would be a good long-term exercise anyway, because people are supposed to be able to do that, and right now it's practically intractable.
11:56pq: frontend is the component that defines e.g. configuration formats and policies
11:59Eighth_Doctor: soreau: funnily enough, zamundaaa and I were talking about that in the context of kwin... it seems kde's dpms protocol is more powerful, and it might be worth making an ext- protocol formally to supersede both wlr-output-management and kde-dpms that compositors can implement
11:59Eighth_Doctor: because the situation sucks as it currently stands
11:59emersion: how more powerful?
11:59emersion: wlr-output-management doesn't do "DPMS"
12:00emersion: ("DPMS" is a legacy name for power management)
12:00emersion: wlr-output-power-management does "DPMS"
12:00zamundaaa[m]: The dpms protocol only differs from the wlroots one in that it has an event for whether or not dpms is supported
12:00emersion: when is that not supported?
12:00zamundaaa[m]: In nested sessions
12:00emersion: wlroots unmaps the surface in that case
12:00zamundaaa[m]: And in general, virtual outputs
12:00emersion: it would be fine to do nothing as well
12:01emersion: i think it makes sense to allow "turning off" a virtual output
12:01wlb: weston Issue #488 closed \o/ (Deprecate and eventually delete non-libseat launchers https://gitlab.freedesktop.org/wayland/weston/-/issues/488)
12:01emersion: IOW: not sure it's worth adding a special-case in the protocol for
12:02soreau: seems like someone should make a MR for s/wlr/ext/ of wlr-output-management and then let the bikeshedding commence ;)
12:02wlb: weston/main: Colin Kinloch * clients/stacking: Fix widget user_data cast type https://gitlab.freedesktop.org/wayland/weston/commit/3f919e3d92ae clients/stacking.c
12:02wlb: weston Merge request !1438 merged \o/ (clients/stacking: Fix widget user_data cast type https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1438)
12:02emersion: yeah i'm not trying that lol
12:02any1:hides
12:03zamundaaa[m]: Yeah. I'd have to check if the capability thing is even used anywhere
12:03emersion: we should probably just re-open wlr-protocols tbh
12:03emersion: i was against it, but it just feels like nothing good is coming out of it
12:03zamundaaa[m]: Oh, talking about wlr-protocols, could you take a look at https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/merge_requests/123?
12:04emersion: ah right
12:04Eighth_Doctor: soreau: I am seriously tempted
12:04soreau: Eighth_Doctor: it won't happen if no one moves it forward
12:05zamundaaa[m]: Fwiw I don't see KWin adopting the wlroots or an ext output management protocol. At least not as a replacement for the kde proto
12:05soreau: that's their problem though
12:05emersion: zamundaaa[m]: last time i looked at it i thought the KDE one could sit on top of the wlr one?
12:06emersion: that would be nice
12:06emersion: i've tried hard to make the protocol externally-extensible when designing the wlr proto
12:06Eighth_Doctor: the fragmentation on these basic protocols is extremely irritating because all the little utilities with incompatibilities or unknown uselenessness makes things very hard
12:06Eighth_Doctor: *uselessness even
12:07zamundaaa[m]: It would be possible, but possibly more effort than supporting two entire protocols. KWin's internal architecture is almost entirely ignorant of the underlying protocol
12:07emersion: ;_;
12:07zamundaaa[m]: I'll give implementing it a try when I have time
12:08emersion: let me know if the wlr proto is lacking in some way
12:08Eighth_Doctor: maybe I should just take the existing one and submit it :/
12:08Eighth_Doctor: then I can drop the dumb "unstable" name that exists
12:08wlb: weston/main: Derek Foreman * libweston: Clip damage to paint node visible region https://gitlab.freedesktop.org/wayland/weston/commit/e74f2897b940 libweston/compositor.c
12:08Eighth_Doctor: I don't think that protocol has changed in a backwards incompatible way in forever
12:08wlb: weston Merge request !1441 merged \o/ (libweston: Clip damage to paint node visible region https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1441)
12:09emersion: yeah, a lot of protocols predate the "staging" era
12:10Eighth_Doctor: the reason I hadn't bothered before is that the wayland-protocols rules are too onerous right now
12:10Eighth_Doctor: but supposedly the rules will be relaxed for ext-
12:10Eighth_Doctor: at some point
12:10Eighth_Doctor: maybe
12:10emersion: i don't think so
12:11Eighth_Doctor: arent you the one that opened the MR for that?
12:11Eighth_Doctor: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/192
12:12emersion: yeah, but i don't think it's a good idea to clutter ext- with protos that may be specific to a single compositor
12:13Eighth_Doctor: yes, but who would do that?
12:14Eighth_Doctor: right now, the current situation is that it's too hard to get an xdg protocol, and there are effectively no avenues for protocols that are adopted by some and ignored by others
12:15wlb: wayland-protocols Merge request !192 closed (governance: relax ACK requirements for the ext namespace)
12:15emersion: ext is that avenue
12:16soreau: the more protocols that get upstreamed to w-p, the more chance that the ecosystem utilities as a whole will start cooperating better together
12:16Eighth_Doctor: emersion: not right now, even ext protocols are stuck
12:17emersion: some are stuck because of disagreements between compositors
12:17emersion: some are stuck because only a single compositor cares
12:17emersion: either way, the solution isn't that MR to relax rules
12:18Eighth_Doctor: true
12:18Eighth_Doctor: the solution needs to be that a single NACK can't kill everything
12:18emersion: nobody has been NACK'ing
12:18emersion: it's just unresolved discussions, or missing ACKs
12:18emersion: (ext can't be NACK'ed anyways)
12:19Eighth_Doctor: well then, I guess I'll try with output-management then
12:19Eighth_Doctor: we'll see how that goes, watching ximion's adventure though was somewhat disheartening
12:20emersion: note about that proto, there is https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/merge_requests/116
12:20emersion: also https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/merge_requests/117
12:20emersion: but the latter probably not a good idea
12:20emersion: still unsure how these mode aspect ratio flags should get exposed to users
12:21Eighth_Doctor: hmm, that would be needed for Weston too
12:21Eighth_Doctor: since it exposes configuring the aspect ratio
12:22emersion: i think the right thing to do is to disregard modes with flags, and let the compositor set it depending on fullscreen surface aspect ratio
12:22emersion: and/or a dedicated aspect ratio protocol
12:23emersion: but that needs a modeset
12:23Eighth_Doctor: I am not sure why aspect ratio is a settable thing
12:23emersion: sigh
12:23Eighth_Doctor: it's usually derived from the WxH, no?
12:23Eighth_Doctor: or am I missing something here?
12:23emersion: the EDID allows setting a picture aspect ratio different from mode aspect ratio
12:23Eighth_Doctor: O.o
12:24emersion: well, not EDID, rather the HDMI InfoFrames and such
12:24Eighth_Doctor: okay I guess
12:24Eighth_Doctor: is that what makes "black bars"?
12:24pq: non-square pixels are a thing
12:24Eighth_Doctor: oh right, that
12:24Eighth_Doctor: I should have remembered that, since I know of OLED panels like that
12:24emersion: if you watch a 16:9 movie on a 4:3 screen, you'd use a 4:3 mode with a 16:9 picture aspect ratio
12:24emersion: pq, i think that's unrelated though?
12:25pq: picture aspect ratio is about non-square pixels, AFAIK
12:25emersion: vsyrjala: ^ do you know details?
12:26emersion: pq, that doesn't match my recollection of the EDID spec
12:26emersion: CTA*
12:26emersion: but maybe i'm misremembering
12:26pq: I can't think of what else it could be, if not for non-square pixels. Otherwise there would be no need to send anything else than width and height.
12:27pq: in pxiels
12:29emersion: pq, https://files.catbox.moe/3b91qi.png
12:30emersion: and https://files.catbox.moe/bl8oqg.png
12:30emersion: and as always now i'm even more confused than before
12:30emersion: but fairly sure it's not about non-square pixels at least?
12:39wlb: weston Issue #866 opened by Pekka Paalanen (pq) RFC: Modernizing configuration management https://gitlab.freedesktop.org/wayland/weston/-/issues/866 [Weston frontend]
12:44pq: Eighth_Doctor, https://gitlab.freedesktop.org/wayland/weston/-/issues/719
12:49pq: emersion, are those about CEA modes? VIC? They don't look familiar.
12:50emersion: this is the definition of picture aspect ratio
12:50pq: I'm thinking more of DRM_CLIENT_CAP_ASPECT_RATIO
12:52emersion: that's the same thing
12:52emersion: this cap enables the picture aspect ratio flags in mode
12:54emersion: i kind of wish ATOMIC didn't implicitly enabled this cap…
13:03pq: emersion, if look at CTA-861-H, section 4.1 Aspect Ratio, there is a table with lots of modes with Pixel Aspect Ratio other than 1:1.
13:03emersion: right, but that's not the picture aspect ratio flag
13:03pq: how is it not?
13:03emersion: picture aspect ratio ≠ pixel aspect ratio
13:04emersion: well, it's just two different concepts?
13:04pq: looking at the table, pixel aspect ratio is derived from resolution and picture aspect ratio.
13:06pq: IOW, picture aspect ratio can be chosen to result in either square of non-square pixels, depending on each mode. Some modes do not even have a square pixel variant.
13:06pq: *or
13:06pq: this is the VIC list
13:07pq: picture aspect ratio flags in KMS are just used for choosing the right VIC, because resolution alone is not enough
13:07pq: and there's a ton of VICs with non-square pixels - like there are MPEG etc. videos as well, I believe
13:09pq: FWIW, Wayland clients can provide non-square pixels to the compositor using wp_viewport, but we do not have a way to tell clients what would match the display.
13:09emersion: hm, ok
13:10pq: or does fractional scaling help there?
13:10emersion: no, it just sends a single factor
13:10pq: d'oh
13:30wlb: wayland Merge request !362 opened by Simon Ser (emersion) build: add a gen-scanner-test target https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/362
15:52zxrom: My two different old Microsoft IntelliPoint 3 and 4 mice are behaving strangely. More than a year ago, the scroll wheel started working spontaneously. Perhaps the new mouse input processing module has removed protection against this behavior of these mice? I have already disassembled and cleaned everything from dust. It did not help. Who has a similar problem? Anyone have any ideas?
15:53bl4ckb0ne: there has been a change recently regarding scrolling wheel
15:53bl4ckb0ne: https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/652 ok 2 years ago
15:53bl4ckb0ne: what's your compositor?
15:53zxrom: Recently is it a year and a half or two years ago? It seems there was another input module before.
15:54zxrom: XOrg, LXDE,Openbox
15:54zxrom: libinput
15:54zxrom: ArchLinux
15:56zxrom: This bug shook my nerves! This works on taskbar buttons often. I usually leave the mouse pointer there.
15:56zxrom: :D
16:00zxrom: bl4ckb0ne, Perhaps from high resolution mouse wheel scrolling to return the old behavior?
16:00bl4ckb0ne:shrugs
16:00bl4ckb0ne: cant say much about x11 DE
16:00zxrom: Is it possible to disable high resolution mouse wheel scrolling to return the old behavior?*
16:03zxrom: I wonder if this module misses real mouse wheel triggers or erroneously generates them internally due to some algorithms? I have not seen this behavior of the wheel in Windows.
17:38vyivel: from compositor side, is there a way to stop new clients from connecting?
17:39kchibisov: Instantly kill them?
17:40vyivel: that's what i'm doing right now but maybe there's a better way
17:40kchibisov: It boils down to unix socket APIs.
17:40vyivel: right
17:41emersion: you can close the listener
17:41emersion: but i don't think libwayland lets you access it
17:41emersion: we have a function to disconnect all clients
17:42kchibisov: they want a way to not add new clients, but keep the already connected ones, I think.
17:42vyivel: the context is i'm doing some cleaning up between wl_display_destroy_clients() and wl_display_destroy() which involves dispatching events though now i'm realising i don't really need to do that
17:47vyivel: nope, still do
17:47vyivel: whatever, client_created listener with wl_client_destroy() works