10:39 javierm: tzimmermann: could you please take a look to https://github.com/fwupd/fwupd/issues/7598 and chime in ?
10:45 javierm: tzimmermann: my gut feeling is that the solution should be to expose the original firmware provided framebuffer size and format if user-space wants to know that
10:45 javierm: e.g: /sys/firmware/efi/efi-gop/{width,height,format}
10:49 tzimmermann: javierm, they are using efifb? and they want to extract framebuffer settings?
10:49 tzimmermann: but efi-framebuffer.0 is missing?
10:51 tzimmermann: efi-framebuffer.0 is the platform device
10:51 tzimmermann: the native driver removed it via aperture helpers
10:53 javierm: tzimmermann: yes I know, I've explained that to them already
10:54 tzimmermann: i'm still trying to understand the bug report. it seems like there are multiple issues
10:54 javierm: but basically what they want is to know what is the system framebuffer size used so that they can put a BMP with the message that the system firmware is being updated
10:55 javierm: tzimmermann: yeah, it's noisy because the people were confused about efifb vs simpledrm and old kernels not removing the conflicting devices vs new kernels doing it
10:55 javierm: tzimmermann: the important is the use case and what they need. Which is as mentioned the size of the firmware provided framebuffer
10:57 tzimmermann: the screen resolution is not stable. i guess that your suggestion of using the bgrt is sound
11:21 javierm: tzimmermann: I just discussed with Richard (fwupd maintainer) and he says that can't make assumptions about where the vendor logo is
11:22 javierm: i.e. we don't know if the vendor logo is in the top left or in the center etc, and fwupd wants to just put a "don't power down during the update" in the users language text below
11:22 javierm: tzimmermann: do you think that's reasonable to expose the screen_info data or as mentioned the EFI-GOP in /sys/firmware/efi/ ?
11:23 tzimmermann: javierm, this is old information
11:23 tzimmermann: they'd ideally use the drm api to read the preferred mode
11:24 tzimmermann: that's likely what the system preferrably boots
11:24 tzimmermann: or they also read the BGRT and use whatever is smaller
11:24 javierm: tzimmermann: but the preferred mode is not necessarily the mode used by the firmware on boot
11:24 tzimmermann: javierm, but it's likely
11:25 javierm: that is, if the real DRM driver did a modeset then the preferred mode would be different
11:25 tzimmermann: the preferred mode is picked from the EDID
11:25 javierm: tzimmermann: ah, right
11:25 tzimmermann: the preferred mode is picked from the EDID
11:25 tzimmermann: and that's likely the native resolution of the display
11:25 javierm: tzimmermann: that's a good point. Likely the firmware also choses their own resolution for the EFI-GOP from the EDID
11:26 tzimmermann: exactly. i know it's not 100%, but still...
11:26 javierm: tzimmermann: yeah, it's a much better heuristic
11:26 javierm: tzimmermann: can you please comment that in the github issue ?
11:26 tzimmermann: didn't i?
11:26 tzimmermann: or maybe let me clarify
11:27 javierm: tzimmermann: no my bad. I didn't refresh it :)
11:27 javierm: tzimmermann: thanks a lot for your comment there
11:28 tzimmermann: ok, i mentioned the edid
11:30 javierm: tzimmermann: cool, I seconded you. That indeed sounds like the most robust approach
11:31 tzimmermann: i don't think there's a way of configuring this in uefi?
11:31 javierm: tzimmermann: they can use a combination of both, to know also the vendor logo size and offset, to place the text correctly
11:31 tzimmermann: yeah, probably a combination of both should be on the safe side
11:32 tzimmermann: AFAICT, systems with CMS enabled sometimes boot with a low resolution
11:34 javierm: tzimmermann: but systems with CMS enabled won't boot on EFI mode anyways and so fwupd won't work
11:34 tzimmermann: oh, ok. good point :)
11:35 javierm: :)
14:22 tzimmermann: javierm, do you still want to review the bochs update?
15:40 DavidHeidelberg: karolherbst: robclark nextafter CL tests should work properly now, if you want to enjoy DooM like eye-bleed, feel free to look at my code: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/950
15:52 karolherbst: I wished there would be a better way..
16:01 javierm: tzimmermann: yes, I had on my backlog. I'll try to do it tomorrow, or do you already have that set reviewed/acked to push ?
16:05 tzimmermann: javierm, gerd hoffmann, the bochs maintainer gave an ack
16:08 javierm: tzimmermann: ah, then feel free to just land it :)
16:11 tzimmermann: javierm, thanks a lot. you've done more than a fair share of reviews for me recently
16:11 javierm: no worries
18:01 austriancoder: DavidHeidelberg: ahh .. you are making progress :)
20:44 DemiMarie: Can someone kick james_scott_001?
22:00 karolherbst: DemiMarie: who?
22:00 karolherbst: is this another matrix bug?
22:01 karolherbst: but seriously... matrix should really fix that bug, because otherwise if on the matrix side accounts can harass/spam/whatever without any moderator noticing here, I don't see how we can continue allowing matrix connections...
22:03 DemiMarie: karolherbst: not a matrix bug
22:03 HdkR: +M?
22:03 DemiMarie: the problem is that this is a portaled room, meaning that the only Matrix-side admin is the bridge bot
22:03 karolherbst: sounds like a matrix bug to me (or a bug in the bridge)
22:04 karolherbst: why do people see messages from accounts not allowed to write on the IRC side?
22:04 karolherbst: it's really a show stopper if you want to enforce moderation in any way
22:04 DemiMarie: Not sure
22:04 karolherbst: it's a known issue and nobody bothers fixing it
22:04 DemiMarie: another option would be to setup the room as a bridged room, meaning that there are admins on both sides
22:04 DemiMarie: s/bridged/plumbed/
22:04 karolherbst: why?
22:05 karolherbst: sounds like more work for us to workaround a buggy bridge
22:05 karolherbst: honestly, the bridge should just be fixed, so it's fixed for everybody
22:05 DemiMarie: because IRC is horrible if one does not either have a permanently-online device or pay for a cloud service
22:05 karolherbst: that's another topic
22:05 karolherbst: obviously, if we use something else and don't use the matrix bridge anymore, the bugs in the matrix bridge don't matter
22:05 DemiMarie: yes, it should, but it’s some Node.js application I don’t know if anyone here understands
22:06 karolherbst: but as it stands today, it's a bug in the brige
22:06 karolherbst: and it should be fixed
22:06 DemiMarie: correct, but I’m explaining why so many people choose to connect via Matrix
22:06 DemiMarie: IRC has massively fallen behind the times
22:06 karolherbst: I don't disagree
22:07 DemiMarie: Notably Mozilla has switched from IRC to Matrix entirely
22:07 karolherbst: sure
22:08 karolherbst: but it's still besides the point, that the matrix bridge has issues it shouldn't have. Sounds like "ah yeah, our bridge is buggy and it's totally your problem because we don't care, but hey, the solution is to use our software ;) ;) ;)"
22:08 DemiMarie: I agree that the bridge is buggy
22:08 Company: DemiMarie: IRC is a chat platform, matrix is a messaging platform
22:08 Company: IRC hasn't fallen behind
22:09 karolherbst: I don't really have confidence in matrix if the main bridge has such moderation issues
22:09 karolherbst: why should I belive that matrix itself is any better?
22:09 DemiMarie: karolherbst: from a moderation perspective the best platforms are the proprietary ones, sadly
22:09 karolherbst: well.. and apparently IRC
22:10 karolherbst: becuase we didn't see the spammer or whatever it was here
22:10 DemiMarie: IRC isn't great either
22:10 karolherbst: well
22:10 karolherbst: you did see the spammer, I didn't
22:10 DemiMarie: Company: synchronous chat is not usable as a primary contact point
22:11 Company: DemiMarie: the primary contact point is gitlab/github usually
22:11 karolherbst: but sure, IRC isn't great eitehr. I'm just saying, that if a chat platform or whatever is causing such moderation problems knowingly (and I know they are aware of the issues), why should I believe that their software is any better?
22:11 DemiMarie: and I do mean "not usable": if one cannot be online when the other person is, one cannot make contact
22:11 DemiMarie: Company: for a project, yes, for a person, no
22:12 karolherbst: but I am using matrix, and it has issues I'd rather it wouldn't have
22:12 DemiMarie: karolherbst: I suspect their funding mostly comes from B2B enterprise contracts
22:12 karolherbst: sure
22:12 Company: DemiMarie: yes, that's by design - you need a messaging platform for that
22:12 karolherbst: I don't think anybody here minds moving to something else, it's just hard to find that something else which is worth the effort
22:13 karolherbst: I've tried a couple of things and I'd probably choose matrix as the last resort
22:13 DemiMarie: What else have you tried?
22:14 karolherbst: zulip, rocket, and uhm... what was the name?
22:15 DemiMarie: mattermost?
22:15 karolherbst: nah.. something else
22:15 DemiMarie: I know that Xen switched to Matrix and Rust uses Zulip.
22:15 DemiMarie: Slack? Discord?
22:15 DemiMarie: Wire?
22:15 karolherbst: I meant open source
22:15 DemiMarie: Wire is IIRC
22:16 karolherbst: yeah dunno...
22:17 karolherbst: maybe it was Mattermost afterall
22:19 DemiMarie: I know that for me personally losing the Matrix bridge would be extremely annoying
22:19 karolherbst: yeah....
22:19 karolherbst: I was joking mostly, but not 100%
22:20 DemiMarie: I think Matrix’s main problem is that it is too decentralized.
22:20 karolherbst: it depends on how painful it gets
22:20 karolherbst: because atm I don't even know how bad the situation is
22:20 DemiMarie: I just ignore each spammer that shows up, but there likely needs to be one admin on the Matrix side to delete junk
22:20 karolherbst: sure
22:20 karolherbst: but.
22:21 llyyr: >because IRC is horrible if one does not either have a permanently-online device or pay for a cloud service <-- self hosting a bouncer is free if you already have a vps, which you probably do
22:21 karolherbst: it's such an obvious problem, I think I'm just disappointed that people didn't bother fixing it yet
22:21 DemiMarie: llyyr: I do not
22:21 DemiMarie: and also one needs two to avoid downtime for security updates, and I'm not sure if any of the bouncers work in an HA configuration.
22:21 karolherbst: though I also ran into issues with pms and matrix users
22:21 karolherbst: but I know that on matrix that's all better
22:21 karolherbst: ther eis just a lot of things to setup to do it all properly
22:22 DemiMarie: IRC just needs to support fetching message history.
22:22 karolherbst: I think if somebody would invest the time to set it up properly and I mean like moderation bots, room repair bots, etc.. etc... then it might make sense to switch and have a bridge from IRC to matrix
22:22 karolherbst: but...
22:22 karolherbst: somebody with the proper knowledge would have to do it and convince the others that it's a good idea
22:23 DemiMarie: Matrix is federated and a room does not belong to a single server. This is serious problem because it means that there is no total order of messages. Enforcing such an order would require either kicking out servers that respond slowly or create a vulnerability to denial of service attacks.
22:24 DemiMarie: That means that Matrix rooms are giant CRDTs, which makes the implementation incredibly complex.
22:24 DemiMarie: Having a single server be the source of truth for a room would solve the problem, because that server could maintain a total order of messages.
22:25 karolherbst: I've heard there are bots to "repair" rooms once they break
22:25 DemiMarie: Earth is small enough that the latency from going all the way around the world is small enough for humans to stand.
22:25 DemiMarie: I believe the room bricking problem was a bug fixed in newer room versions.
22:25 Company: isn't it kind of a fundamental flaw of a messaging protocol if messages don't have an order?
22:26 karolherbst: IRC doesn't have an order either, but I mean.. atomics are kinda hard, especially across the network
22:26 karolherbst: though..
22:26 karolherbst: I think in IRC it's usually a client problem, but I don't know if the protocol actually sends you your own messages
22:27 karolherbst: so you might actually not know where your messages fit into the history, but it might also be that clients don't bother reordering
22:28 Company: right, but that's kind of annoying with irc, too
22:28 karolherbst: yeah...
22:28 karolherbst: DemiMarie: anyway.. I think it mostly just need a person with enough spoons to do it all properly
22:29 karolherbst: not sure if there is any other reason we are still on IRC besides nobody cared enough
22:29 Company: you can do it like Gnome: force-transition everyone to matrix
22:29 karolherbst: mhhh
22:30 karolherbst: luckily our community isn't that heavily organized
22:30 karolherbst: so if one or two projects are having their rooms on matrix it won't even matter. I'm sure there are some dunno
22:31 karolherbst: the one benefit of being more organized in regards to the chat platform could be that developers could moderate (as in kick spammers etc..) across channels
22:34 Company: as long as you avoid admin power abuse, that works
22:35 karolherbst: we have that going on IRC already, it's just kinda on demand and various channels have varies people on their access list, it's just very... uhm.. random
22:47 DemiMarie: Should regressions in Fedora Mesa packages be reported to Fedora or Mesa?
22:52 kisak: Randomly from the internet: "./bin/glnxa64/MATLABWindow: /home/eric1/Downloads/matlab_R2024a_Linux/bin/glnxa64/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /lib/x86_64-linux-gnu/libgallium-24.2.1 - kisak-mesa PPA.so)"
22:53 kisak: are we really naming libgallium off of VERSION?
23:12 mattst88: kisak: yes (I don't know the reason why), but there's a unversion-libgallium configuration option to turn it off
23:35 kisak: I think for my purposes, as long as it's not broken, then I'm not going to deviate from upstream Debian packaging. It's just unexpected.
23:40 kisak: the rest of that error is just matlab naively shipping libstdc without considering it might end up on a newer distro.
23:57 mattst88: kisak: https://gitlab.freedesktop.org/mesa/mesa/-/commit/9b7bb6cc9fa410fb783e7a99d9eadcc31668f298
23:58 mattst88: ah, the purpose is to indicate to developers that they should not link against it