00:56 i509vcb: Company: I've had the idea if I ever have too much time to write a desktop of using a compositor widget to show results of settings as you edit the settings.
01:00 Company: the problem with settings is usually that they have effects outside of just the UI
01:00 i509vcb: yeah whether it's practical is a whole other question
01:03 Company: the interesting thing with a widget is that you can use it to host other things
01:03 Company: and wrap some UI around it
01:03 Company: like Steam
01:04 Company: or hosting different emulators
01:09 soreau: *changes setting* ... *settings ui disappears* ...
04:41 wlb: weston Issue #940 opened by Hunter Laux (hunterlaux) failed to check FreeRDP WTS VC file descriptor for https://gitlab.freedesktop.org/wayland/weston/-/issues/940
05:00 wlb: wayland Issue #488 opened by Demi Marie Obenour (DemiMarie) Document semantics of multi-plane YUV formats in wl-shm https://gitlab.freedesktop.org/wayland/wayland/-/issues/488
10:28 emersion: swick[m]: i really don't appreciate your behavior on libdisplay-info
10:33 emersion: just because we disagree on something, doesn't mean you have to bust your way through
10:34 swick[m]: Back when we started libdisplay-info together, you wrote MRs, I always reviewed them timely and with the clear goal of getting things merged. you stopped writing MRs which is completely fine, but you also stopped reviewing MRs. I have to fight very hard to just get anyone to take a look at anything. When you then decide to take a look, I get very vague "I don't like this" reviews, followed by multiple month of silence again. I'm not even sure
10:34 swick[m]: you're actually taking a look at the code and the specs because then you'd notice why things are the way they are.
10:35 swick[m]: the project has stalled
10:36 swick[m]: if you don't want or can't maintain the project anymore, then I don't think it's fair for you to block any progress with a vague "I don't like this" comments every few month
10:37 kennylevinsen: considering that the underlying review disagreement is opinion on design, asking a second reviewer for a tie break might be a good idea.
10:37 swick[m]: if there were any reviewers, that would work
10:37 swick[m]: I reached out to a bunch of people, trying to get more involvement in the project but it was unsuccessful
10:38 swick[m]: so, let's put it this way: I also don't appreciate your behavior emersion. I spend a ton of time, all for nothing.
10:38 kennylevinsen: just from reading the PR it looked like the ping for pq and zamundaaa was less than 24 hours ago
10:39 swick[m]: yes, but pq is out, and zamundaaa doesn't want to make design decisions. he only agreed to review code because I reached out to him, because the project is stalled.
10:39 emersion: i really try to _not_ do "I don't like this" reviews
10:40 emersion: i really try to explain the reasons
10:40 emersion: when i posted "still prefer not to merge" in the other MR, i felt the reasons were explained in the comments above well enough
10:41 swick[m]: good on you for trying. the 3 reviews I got in the last half year were not actionable.
10:41 swick[m]: looking at the git history also is telling a story
10:44 emersion: that's an unfair description
10:44 emersion: plenty of MRs were merged in the last half-year
10:44 emersion: https://gitlab.freedesktop.org/emersion/libdisplay-info/-/merge_requests?scope=all&sort=merged_at_desc&state=merged
10:44 emersion: i spent a lot of time on reviews
10:46 emersion: i don't think "i'll just force merge without reviews" is a good answer to "simon is no longer paid to work on libdisplay-info"
10:48 kennylevinsen: emersion: to be fair, as a third-party reader I do feel that the dismissal could use an invitation for dicussion. E.g., rather than just say that you don't see any benefit, you could ask to have the intended benefits (any why they are needed) explained
10:49 kennylevinsen: granted, it fell off a cliff way faster than this MR alone justified
10:49 emersion: yes, i agree that i could've done better
10:58 swick[m]: you can see more than half a year of commits on one page
10:58 swick[m]: I'm not saying you have to do more work, I'm saying the current way doesn't work
10:59 emersion: patches get stuck on projects all the time
10:59 kennylevinsen: do note that a different governance does not imply that a particular MR would pass review
10:59 emersion: you've tried to bring in more reviewers, which was a very good idea
10:59 swick[m]: I had this exact same discussion on another project just yesterday
11:00 emersion: another strategy is to ping every week or so
11:00 swick[m]: other projects dysfunctions are not an excuse. this is whataboutism.
11:00 emersion: i'm not saying it's a good situation here, i'm saying it's a well-understood problem
11:01 kennylevinsen: I would have to read up on seemingly a handful of specs to be useful for review
11:02 swick[m]: it is a well-understood problem, and maintainers without time stalling the project when others could take over and build momentum is a possible solution
11:04 kennylevinsen: would you be happy if a very active maintainer declined the MR quickly?
11:05 kennylevinsen: stalled work sucks, but increasing maintainer activity does not imply a particular outcome
11:06 swick[m]: rejecting MRs happens either way. the difference is waiting half a year for it to happen or half a week.
11:07 swick[m]: I tried everything to get more people into the project and get my work reviewed, but it's not happening
11:08 swick[m]: I'm currently the only person working on the project and if I can't get work reviewed, the only possibility that I see is a fork
11:08 kennylevinsen: I'm reading up on the specs, maybe I'll end up chiming in
11:08 kennylevinsen: no guarantees though
11:09 swick[m]: or emersion giving up a bit on control
11:09 swick[m]: kennylevinsen: thanks, appreciated!
11:09 emersion: i don't think you've pinged enough
11:10 swick[m]: don't start to blame this on me
11:10 swick[m]: it's not like there are hundreds of MRs that you might miss
11:10 emersion: i'm not blaming anything
11:10 swick[m]: no, that is literally blaming me
11:10 emersion: it's not about "missing"
11:11 swick[m]: at any point in time, you can go here: https://gitlab.freedesktop.org/emersion/libdisplay-info/-/merge_requests
11:11 emersion: example ping interaction https://github.com/intel/libva/pull/790
11:12 emersion: having contributors ping about patches helps me tremendously, and it's something i've heard other maintainers say a lot as well
11:12 swick[m]: this took multiple month and that might be acceptable if you're interested in getting a single MR in
11:12 emersion: otherwise patches just get lost in my inbox
11:13 swick[m]: I don't know why you're still justifying that it takes month to get a single, simple feature into a not that complex project
11:13 swick[m]: do you really think this is accaptable?
11:13 kennylevinsen: swick[m]: you're the one solely blaming simon's maintainership, it's perfectly fair to counter
11:16 swick[m]: I've exhausted every other possibility at this point
11:16 kennylevinsen: pinging *could* have helped reduce the 3-month wait
11:16 kennylevinsen: but I do agree that the options are limited with only a single viable reviewer if they others have left openly left the ring
11:16 swick[m]: I can find MRs where I pinged more and which didn't go anywhere
11:17 swick[m]: and trying to ping someone every week to do anything on a project isn't accaptable
11:19 swick[m]: like I said, I see exactly two possibilities right now: I'm merging my own stuff after some time when I'm not getting proper reviews or I start forking the project and do the same somewhere else
11:19 swick[m]: open to other suggestions ofc
11:19 kennylevinsen: if I joined as a reviewer I wouldn't be polling the merge request list, and with attention split amongst clients I'm likely to miss any initial notifications
11:19 kennylevinsen: so needing *some* form of ping seems natural. It's not implied that you should ping every single week for months on end though.
11:19 swick[m]: yes, I'm not saying you're not allowed to miss a single MR ever
11:20 swick[m]: I'm saying that if I have to ping someone for weeks on every MR, we got a problem
12:47 MrCooper: who quietened swick, and what for?
13:00 dwfreed: MrCooper: well, it can only be one of 4 people, and one of those 4 people was in the conversation, so that's probably a safe bet
13:10 daniels: I was the one who applied +q
13:11 dwfreed: well, I did have a 75% chance of getting it wrong
13:13 ManMower: probably not a great thing to be guessing about, tbh
13:18 daniels: ^
13:19 daniels: as with other fd.o spaces, we (collectively) moderate in accordance with https://www.freedesktop.org/wiki/CodeOfConduct/
13:21 dwfreed: I mean, I could have looked, but then people would be complaining about abuse of power, etc
13:24 daniels: is that something we should expect from OFTC?
13:26 dwfreed: If it is necessary, we do use powers to look
13:26 daniels: when would you deem it necessary?
13:27 dwfreed: there's no hard and fast rule, it is a case by case basis
13:27 daniels: if I hadn't said that it was me, would you have looked and said that?
13:27 dwfreed: no, probably not
13:28 dwfreed: and if I had, I would not have said it publicly regardless
13:36 dwfreed: (clarification: I would not have said that it was you publicly if I had used powers to look; it would have only been shared privately with those that needed to know)
13:37 daniels: right, I'm not really clear on even the principle of how 'needed to know' would be determined
13:40 daniels: like, is the expectation that you're looking to see if chanops are abusing powers or have potentially had their account compromised, or is the expectation that for every moderation action we should expect an individual to be publicly outed as responsible and presumably required to explain themselves publicly?
13:40 dwfreed: for the latter, definitely not
13:40 daniels: so I'm still not clear on 'needed to know'
13:41 dwfreed: for this, I would say generally it would be if someone should already have access to that information, but for reasons not immediately remediable does not; in this particular instance, given access lists elsewhere in FDO channels, if he'd asked, I probably would have told MrCooper privately
13:42 daniels: cf. the fd.o CoC where we a) take decisions collectively rather than individuals randomly doing things (to avoid individuals being targeted for guilt trips and/or abuse), and b) default to not outing the full details in public (to avoid effectively slandering people, as well as to give people the opportunity to start with a clean slate rather than have a permanent '$foo is bad because ...' record when they come back as a good citizen)
13:42 dwfreed: (already have access meaning able to do the '/msg ChanServ quiet #wayland list' themselves, which is restricted to chanops and above)
13:42 wlb: weston Merge request !1590 merged \o/ (color: update color-management protocol to xx-v4 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1590)
13:42 wlb: weston/main: Joan Torres * color: update color-management protocol to xx-v4 https://gitlab.freedesktop.org/wayland/weston/commit/1b793b7acdc7 clients/window.c include/libweston/libweston.h libweston/color-management.c libweston/color-properties.c libweston/compositor.c protocol/color-management-v1.xml tests/color-management-test.c
13:43 MrCooper: FWIW, I don't have access to that for #wayland, or I wouldn't have asked
13:43 dwfreed: perhaps utilizing GroupServ to unify FDO access lists wouldn't be a bad idea
14:38 wlb: weston Merge request !1592 opened by Derek Foreman (derekf) compositor: Unmap views moved to layers outside of the scene graph https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1592 [Core compositor]
15:15 wlb: weston/main: Michael Olbrich * subsurface: don't forget to repaint after the first sub-surface commit https://gitlab.freedesktop.org/wayland/weston/commit/a7e8bd4beaad libweston/compositor.c tests/subsurface-shot-test.c
15:15 wlb: weston Merge request !1480 merged \o/ (subsurface: don't forget to repaint after the first sub-surface commit https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1480)
18:22 wlb: wayland Merge request !418 opened by Fangzhou Ge (fangzhoug) Log the object and methods when marshalling or sending request fails. https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/418
20:38 kiilerix: I got a keyboard with a "copilot" key that I would like to use as Ctrl. evtest shows it sends KEY_LEFTMETA KEY_LEFTSHIFT KEY_F23. I can use xkb modifier_map so wev see it as "Shift Control Mod4 Super". But how can I get rid of "Shift" and "Mod4 Super"?
20:54 kennylevinsen: kiilerix: there isn’t a good way to do what you want - the key doesn’t send 3 buttons at once, it first sends a left shift, then a left meta, then f23, then release…
20:54 kennylevinsen: No way to know in advance that the shift or meta should be muted, and by the point f23 is pressed they’re already emitted as held
20:55 kiilerix: kennylevinsen, thanks for confirming. I'm trying with "interpret" but don't know if that is going anywhere ...
20:56 kennylevinsen: The purpose of a key map is not to pretend buttons work differently or to code macros, but to specify what *symbol* a particular physical sequence scan code emits
20:57 kennylevinsen: E.g., “shift + meta + f23 emits PrintScreen”
21:00 kennylevinsen: You could maybe modify your keymap so “meta shift super” triggered the same layer as “super”? Haven’t tried hacking that much with xkb layouts
21:02 kiilerix: yes ... it is possible to map any key to work as Control, so there seems to be an almost-usable translation layer before it gets to emitting symbols
21:03 kennylevinsen: Mapping a key A to a key B is trivial
21:03 kennylevinsen: That’s not what you want
21:03 kiilerix: and yes, I guess it could work if the "Shift Control Mod4 Super" layer was the same as the "Control" layer ...
21:03 kennylevinsen: That’s my best guess so far at least
21:05 kennylevinsen: It won’t hide that shift and meta is held
21:05 kennylevinsen: But you get to control what the final symbol becomes
21:07 kennylevinsen: However if your goal is just to use it in keybinds, just bind it as is after converting F23 to a modifier. Better than fighting your hardware.
21:07 kennylevinsen: And throw rocks at whoever came up with such shitty keyboard firmware
21:09 kiilerix: it seems like it is the way MS wants that key to work on *all* keyboards in the future
21:10 kiilerix: that too shall pass, but until then my request might be common ...
21:13 kennylevinsen: Not something easily fixed in software. If we wanted to have a workaround, it would require something to realize it’s f23, then first emit a *release* of the already pressed meta and shift keys, *then* emit the substituted key, re-emit the press of meta and shift, and then release them as they keyboard does…
21:14 kennylevinsen: Either in the display server or in xkbcommon
21:15 kennylevinsen: It’s not a new problem, laptop manufacturers have always made these kinds of hotkey hacks whenever they wanted a “unique” button - and they’re always annoying, regardless of OS
21:21 kennylevinsen: I really don’t get why they felt a need to hold modifiers when they’re already sending something as unused as f23 :/
21:27 dottedmag: Well, I can imagine meetings inside Microsoft: "— Let's come up with an unused key combination. — Uhm, F23? — Nah, someone might have used it for something. — All right, Alt+Shift+F23? — Okay, that sounds good"
21:28 kiilerix: yes, but it is a problem that can be solved by introducing an extra level of indirection ... and the input stack already has so many knobs that it seems unlikely that it can't be solved with configuration already
21:29 kennylevinsen: kiilerix: it cannot be solved by indirection - you want left shift to be hidden, but that’s the same as your real left shift key
21:30 Arnavion: I guess the indirection could send the release of shift before the press of F23 so that to the higher layers it just appears as someone pressed and released shift and then separately pressed f23
21:32 kennylevinsen: For keybinds to work you’d need that horrible hack yeah
21:32 kennylevinsen: For layers you could just modify the key map to have a layer trigger when those are held
21:32 Arnavion: I wonder what happens if you press the real shift and the copilot key
21:33 kennylevinsen: I’ve seen a few different things. Sometimes the weird laptop keys are a different keyboard altogether for example
21:34 Arnavion: Does the keyboard send two shift presses? Does it skip the shift press but still sends the shift release when you release the copilot key even though you still have shift held? Or does it properly "refcount" the keypresses: :D
21:34 Arnavion: Ah if it pretends to be a different keyboard then it would be easy, yeah
21:36 kennylevinsen: kiilerix could tell us with the evtest output though :)
21:37 kiilerix: evtest reports that it releases shift in the same syn_report as it presses leftmeta, a moment later it presses shift again
21:38 Arnavion: Haha
21:41 kennylevinsen: It would actually be much easier to deal with if it was a separate keyboard entity :/
21:42 kennylevinsen: Then you could actually just map the scan codes for shift and meta to something bogus
21:43 kiilerix: it creates 4 input event devices, but is apparently only using one
21:44 kiilerix: https://www.lenovo.com/ca/en/p/accessories-and-software/keyboards-and-mice/keyboards/gy41p80859 would be great for the price if I easily could put custom firmware on it ;-)
21:44 kennylevinsen: Oh it’s an external keyboard?
21:45 kennylevinsen: Thought it was one of those newfangled laptops
21:45 kennylevinsen: We need more companies like framework using qmk as the stock keyboard firmware
21:56 kiilerix: but it seems like it should be possible to work around it with something like SetMods, SetGroup, or RedirectKey ...
22:30 kennylevinsen: SetMods makes it so that the key combo *engages* a modifier. I don’t think you can undo existing modifiers with it.
22:32 kennylevinsen: But we’re getting into hairy xkb territory outside my area of expertise, so some independent research couldn’t hurt.
22:32 kennylevinsen: Some stuff like RedirectKey does not seem to be supported in libxkbcommon
23:12 whot: realistically you can try to work around this but since it's a MS official requirement it's a lot easier to map that combo to a new keysym in xkeyboard-config and move on
23:13 whot: adding heuristics to detect this is going to hurt much more, everyone who cares about keyboard shortcuts already knows how to deal with modifiers anyway
23:16 soreau: compiz comparable compositor - http://blog.northfield.ws/wayfire-animations/ http://blog.northfield.ws/more-wayfire-animations/