01:13 <unrelentingtech> hello hello can anyone see this?

01:15 <wlb> weston Issue #545 opened by Demi Marie Obenour (DemiMarie) Seamless backend support https://gitlab.freedesktop.org/wayland/weston/-/issues/545

01:25 <unrelentingtech> Demi Marie Obenour IRC cannot hear you, you need to manually identify to nickserv via private message (sadly OFTC doesn't do SASL so auto login does not work on the Matrix OFTC bridge >_<) you can use https://oftc.irclog.whitequark.org/wayland to quickly see if IRC can hear you

02:19 <DemiMarieObenour[m]> <unrelentingtech> "Demi Marie Obenour IRC cannot..." <- Does this work now?

02:19 <DemiMarieObenour[m]> (bridge test)

02:41 <Sachiel> yes

08:35 <pq> DemiMarieObenour[m], welcome to irc, at least it worked 6 hours ago. :-)

08:49 <emersion> i really wish OFTC supported SASL :(

09:56 <wlb> wayland-protocols Merge request !115 opened by Carlos Garnacho (carlosg) text-input: Reword the interpretation of serials to be more specific https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/115

10:27 <Arnavion> It supports SASL EXTERNAL with a client cert

10:28 <Arnavion> Might be hard to make that work with a matrix bridge though

10:31 <emersion> it doesn't support SASL EXTERNAL

10:31 <emersion> as in: the SASL IRC extension isn't available

10:32 <emersion> it just so happens that it checks the client cert and auto logs in the user if it matches one in its DB

10:32 <emersion> this is not SASL EXTERNAL

10:32 <Arnavion> Sure. It amounts to the same thing in the end

10:32 <emersion> no: SASL can be automated, and what OFTC does can't

10:33 <Arnavion> (I'm not aware of any client that doesn't call connecting with a client cert "SASL EXTERNAL")

10:33 <emersion> ^ that's the reason of the confusion

10:33 <MrCooper> it's also not as easy to switch back to a registered nick after disconnects as it was with SASL on FreeNode

10:42 <kennylevinsen> Yeah it's a little annoying. I use #mesonbuild as canary for having been disconnected and needing to reidentify in order to speak here - they only allow join with registered nicks, so if I'm not there anymore I need to do something. :P

10:42 <kennylevinsen> Easier to detect than the silent failure of being muted here. :/

10:43 <ifreund> that's a good tip, I'll join that channel exclusively for that purpose. I don't even know if I'm currently muted here or not

10:44 <daniels> ifreund: we can hear you

10:44 <ifreund> excellent, thanks

11:06 <emersion> i think (?) IRC sends you back an error if you can't speak

11:07 <emersion> > the message will not be delivered and the command will silently fail

11:07 <emersion> ah, nvm

11:08 <emersion> well, there is ERR_CANNOTSENDTOCHAN, but not all servers send it

17:41 <romangg> Has there been already some thought spent in the past on creating common configuration interfaces shared between compositors so that desktop/shell components can work with different compositors and vice versa?

17:41 <romangg> Any links to prior art or issue/mailing list discussions?

18:29 <SardemFF7> configuration? like the worst idea X got with Xsettings that resulted in even less consistency because it couldn’t really do what it tried to do so DEs invented their own which led to Freedesktop.org specs that worked much better?

18:30 <SardemFF7> (and X got a lot of bad ideas though IMO some people did a really good job trying to bring some to Wayland, for better or worse…)

18:30 <SardemFF7> [only personal opinion depicted here, nothing official]

18:40 <romangg> SardemFF7: Don't know much about Xsettings. But I meant something like Freedesktop.org specs. For example for configuring input devices. Currently compositors don't have standard interfaces that allow configuring them.

18:41 <romangg> One could say some Wayland protocols already provide such means. But it's spotty and I would be interested in how this topic was discussed in the past.

18:43 <romangg> There are protocols for example to manage the state of connected outputs.

19:00 <bl4ckb0ne> 3/b 14

21:09 <hendursaga> Anyone used AntiMicro with Wayland yet? How was the experience? I see they list Wayland is supported but last time I used it it didn't.

21:11 <hendursaga> And by supported, I mean, the very last release, which was released a fortnight ago..

21:31 <whot> romangg: input configuration is a bit of a pandora's box. either you want mouse/touchpad/... configuration or you want per-device configuration, in which case you now need to worry about device matching, possibly pairing, etc.

21:31 <whot> romangg: ideally you have a combination of both but now you need to also worry about overriding one with the other, etc

21:32 <whot> romangg: it's possible, it's just there are so many corner cases and details and there's a inverse relationship between how common they are and how loud the complaints are

21:57 <romangg> whot: do you mean with "per-device" for each device and with for example "mouse" for all devices that have mouse characteristic?

22:43 <romangg> There are likely a lot of corner issues and questions to be solved, but we should at least push into the direction of providing more and more configuration interfaces. I think it's a striking loss that the modular nature of the Linux desktop has been stiffled by the move to Wayland.

22:54 <leon-p> romangg: you mean like wlr-output-management? (missed an interesting discussion apparently, are there channel logs btw?)

22:56 <romangg> leon-p: There had been channel logs in the past on some webpage for #wayland. But I don't know if that still holds with oftc and don't find the webpage right now anymore.

22:57 <romangg> But there wasn't that much discussion. Most Wayland devs are likely in their weekend.

22:57 <Arnavion> https://oftc.irclog.whitequark.org/wayland/

22:57 <romangg> but yes, I meant protocols like wlr-output-management.

22:58 <leon-p> I see. FWIW over on #river we are interested in a similar protocol for configuring input devices. Would be nice to have something standardized(-ish) as well

22:58 <leon-p> Arnavion: thanks!

22:59 <romangg> leon-p: Interesting. Thanks for letting us know.

23:15 <romangg> leon-p: Are you guys only interested in input configuration or also the configuration of other global state things like gamma, screenlocking, etc?

23:16 <romangg> There is probably a lot which I'm not thinking of right now.

23:17 <leon-p> romangg: we are interested into outsourcing a lot of configuration and policy into external clients

23:18 <leon-p> as an example, we already have a protocol for clients to provide layouts for automatic window positioning

23:19 <romangg> Yea, that is exactly the direction I would want to move into too.

23:19 <romangg> I mean outsourcing configuration and policy into external clients.

23:20 <romangg> imo just makes sense to keep the complexity low in the compositor and for other reasons.

23:21 <romangg> Was this always clear for you guys that this is the direction you want to move in or do you have discussed that plan somewhere I can read up on?

23:29 <leon-p> romangg: It's a conclusion we reached over time. Can't really recall how we arrived there, but we made good experiences already with configuration/policy daemons in the form of kanshi and our own laoyut generators. The CLI UI we currently expose for input configuration is a massive step back compared to that.

23:38 <leon-p> It's not just about outsourcing code. A user may want configuration and policy to change depending on certain rules (like kanshi does), a lot of which we as compositor devs can't foresee or are not willing to implement. Using external clients allows us to support all these use cases without ever wasting a thought on them. In a sense, it allows us to avoid making decisions, so we can be a little less

23:38 <leon-p> oppinionated.

23:44 <romangg> yes, there are probably a lot of reasons. you are also right about making the compositors less opinionated. imo there must be a big coordinated move towards that goal. it's just difficult to get the "big desktops" on board.

23:45 <leon-p> Don't a few of the "big desktops" already have session daemons, that serve a somewhat similar function?

23:46 <romangg> what's a session daemon for you?

23:50 <leon-p> A background service that among other things is responsible for keeping track of certain desktop-wide settings and launching all processes needed. It has been some time since I last looked at the guts of the big desktop, maybe that functionality has been absorbed into the compositor by now

23:59 <romangg> I don't know much about Gnome. I thought there the compositor and shell are pretty much combined and so they don't really have that distinction. But I might be wrong on that. For KDE you got a daemon with modules. Some of them do indeed talk to the compositor through Wayland protocols and/or D-Bus.