00:02 RAOF: So you can test core stuff in wlroots with tinywl, which is still helpful.
00:03 DemiMarie: RAOF: any chance Mir could support xdg-decoration?
00:13 DemiMarie: @orowith2os:fedora.im: if you want apps to be able to use GTK for decorations then GTK had better be an easily embedded in an application, which it isn’t.
00:16 DemiMarie: and do not care about accessibility
00:17 DemiMarie: What I will say is that clients had better implement xdg-decoration
00:18 DemiMarie: Some compositors will draw SSDs whether clients like it or not, and if the client doesn’t notice that the result will be double decorations.
00:50 ids1024: DemiMarie: Generally Wayland is designed on the assumption that servers never draw window decorations (except maybe minimal borders) for clients that don't implement those protocols. But I guess the point here is that Qubes doesn't trust clients to provide their own decorations?
00:51 DemiMarie: ids1024: exactly!
00:54 DemiMarie: @orowith2os:fedora.im: why is this so surprising?
00:55 DemiMarie: @orowith2os:fedora.im: you don’t, it’s the colored borders that matter
00:56 danieldg: yes, qubes is designed with the idea that untrusted clients are likely to play clickjacking games if you let them do their own decorations
00:56 danieldg: plus the colors to indicate which VM the window came from
00:56 DemiMarie: @_oftc_danieldg:matrix.org: yup!
00:58 DemiMarie: @orowith2os:fedora.im: that’s an interesting idea, thanks
01:00 DemiMarie: @orowith2os:fedora.im: trust me, this is _not_ the worst hack Qubes has when it comes to displaying stuff
01:03 DemiMarie: The worst is injecting GTK4 CSS to work around performance problems with software rendering
01:05 DemiMarie: more would not help, sorry
01:07 DemiMarie: Native contexts are the goal, but they will have to be off by default until GPU driver security improves
01:12 DemiMarie: Also, Nautilus might be slow on a 1vCPU VM with software rendering, but it should at least work, not get stuck displaying the spinner forever.
01:46 RAOF: DemiMarie: Sure! xdg-decoration support would be a “good first issue” :) https://github.com/MirServer/mir/issues/664
01:47 RAOF: (I understand Lomiri, one of our downstreams, even implements it)
01:48 DemiMarie:is glad this is possible, unlike in Mutter
02:05 DemiMarie: @orowith2os:fedora.im: I know you were joking about 1 GPU per VM, but if you knew how bad GPU passthrough security was, you would not be recommending this solution. Cloud providers get away with it by using custom hardware.
02:05 DemiMarie: Specifically custom board designs, possibly with custom chips.
05:33 Sachiel: orowith2os[m]: fwiw, you are not identified on irc so we old farts can't read you
09:11 wlb: weston Issue #826 closed \o/ (weston rdp screen sharing https://gitlab.freedesktop.org/wayland/weston/-/issues/826)
09:38 mlausch: don't know if that's the correct place to ask about mouse input events in wayland (actually gnome/Xwayland). `libinput debug-events;' shows me hid++ scroll events, `wev` doesn't.
09:39 mlausch: or i don't know what i'm doing and misread things. I can provide literal output of libinput debug-events and wev if needed.
09:41 vyivel: i don't wev supports axis_value120
09:41 vyivel: don't think*
09:41 vyivel: so no hires scrolling
09:52 mlausch: @vyivel thanks. wev does the right thing. i looked into the source and the wayland proto spec. what i see in wev output is a sequence of 8 axis_source events, followed by 1 axis event. the 1 axis event corresponfs to one ratchet (detent) of the wheel.
09:54 mlausch: which is weird, because wayland server gets all the hid++ events, but only emits axis events after N such hid++ scroll events.
09:54 mlausch: or i don't understand the semantics of the scroll events in the wayland proto (which is a totally valid thing).
10:26 mlausch: vyivel: you're right. i skimmed the mutter source code and the 120 scroll values are not used. so no smooth scrolling in wayland?
10:29 mlausch: vyivel, thanks for the tip.
10:52 pq: mlausch, wayland has it, it looks like: https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/protocol/wayland.xml?ref_type=heads#L2312-2338
11:03 vyivel: yes, and mutter has it too
11:04 vyivel: *wev* doesn't support it
12:04 wlb: weston Issue #830 opened by Kirill Primak (vyivel) A destroyed and recreated wl_subsurface is visible before the pending state of the parent surface is applied https://gitlab.freedesktop.org/wayland/weston/-/issues/830
12:45 wlb: wayland Issue #415 opened by Michele Petrelli (Michele73) Lags visible with wayland on 4k monitor https://gitlab.freedesktop.org/wayland/wayland/-/issues/415
12:49 vyivel: it might be helpful to rename .gitlab/issue_templates/Bug.md to Default.md so the template is visible immediately to reduce the number of issues like the one above
12:56 wlb: wayland Issue #415 closed \o/ (Lags visible with wayland on 4k monitor https://gitlab.freedesktop.org/wayland/wayland/-/issues/415)
14:25 mlausch: pq thanks. i didn't scroll down enough. i'm gonna add it to wev then.
17:38 wlb: weston Issue #831 opened by Link Mauve (linkmauve) Segfault when opening the properties of a layer in Krita https://gitlab.freedesktop.org/wayland/weston/-/issues/831