09:24 pq: emersion, whoa, did we actually convince people to rename "secure buffers" to "restricted buffers"?
09:24 emersion: pq, yeah, i can't believe it
09:25 pq: just another dozen series left to get the memo I guess
09:26 pq: This made me start to think how a "restricted buffers architecture" could be made usable for everyone and not just the few big companies...
09:26 emersion: yeah, too late for GBM_BO_USE_SECURE or w/e
09:29 pq: maybe some kind of public/secure key split; anyone could encrypt their own content with the public key, and only the hardware has the private key for decrypting it. Then some handwaving around restriction levels (how much HDCP or whatnot is enough) and how to manage a bajillion different key pairs because people have different devices.
09:30 pq: Then anyone could publish "eyes only" content - as far as the fallacy of "eyes only" is true.
09:49 karolherbst: how can I run jobs with the correspdoning container locally (and potentially debug them)?
09:53 MrCooper: karolherbst: docs/ci/index.rst "Building locally using CI docker images" might be a start at least
10:02 karolherbst: MrCooper: you know if there is a simple way to pull the env vars used for the build script?
10:04 MrCooper: those set by the CI configuration YAML, or by the script itself?
10:04 karolherbst: by the CI config yaml
10:09 karolherbst: mhh, but also "./.gitlab-ci/meson/build.sh: line 96: uncollapsed_section_switch: command not found"
10:09 ernstp: Struggling with the amd-gfx mailing list and Gmail... "Your membership in the mailing list amd-gfx has been disabled due to excessive bounces"
10:10 MrCooper: karolherbst: don't know any way, would seem like a nice feature addition to https://gitlab.freedesktop.org/mesa/mesa/-/ci/editor?branch_name=main&tab=2 though
10:11 MrCooper: ernstp: #freedesktop is better for that
10:11 ernstp: thanks
10:15 airlied: karolherbst: oh I fought that for a while last week and mostly gave up, but definitely learn to use real docker and not podman :-P
10:15 karolherbst: installing real docker on fedora is pain tho
10:15 karolherbst: (and to get it to work)
10:16 MrCooper: I'd expect podman to work fine for this
10:16 karolherbst: sure, but podman is also podman and has its own caveats
10:17 MrCooper: one crude way is to add 'env' to the job script and run it in CI :)
10:23 mupuf: pq: I guess it would require FPGA-based GPUs to implement that... but honestly, the entire thing is broken anyway so all you need to do is "encrypt the video file" and let the cpu decode it
10:25 karolherbst: mhhh *sigh*.. the error I try to debug doesn't reproduce locally :)
10:40 karolherbst: I blame ccache 🙃
10:40 karolherbst: though I think it's not used in that job
10:41 dolphin: airlied, sima: https://intel-gfx-ci.01.org/tree/drm-next/combined-alt.html <- looks like for drm-next the number of tests run has regressed big time
10:42 dolphin: So I will send the PR, but will be hard to assess on the quality as the drm-next baseline also looks bleak.
10:51 dolphin: PR sent
11:03 pq: mupuf, the point of "eyes only" is that the receiver can decrypt and view but not save/copy the decrypted content. For example photographers who need to give out drafts over email but don't want to give out digital pictures, since they sell specifically hardcopies.
11:03 mupuf: oh, right!
11:03 mupuf: now I get your point
11:04 pq: Very much like Digital Rights Management, but available to everyone rather than just the cabal of big companies.
11:06 pq: of course, if you can view, you can also copy, so the whole premise of "eyes only" is false
11:07 pq: just like one can put a hardcopy photo into a scanner
11:08 tleydxdy: except it's not tho
11:08 tleydxdy: they can just videograph the whole time you are looking at it
11:09 tleydxdy: all that we have right now is just foreplay to get people comfortable
11:10 javierm: maybe more like "receiver only with the same image quality that was sent"
11:10 tleydxdy: tv with cameras are coming very soon
11:24 pq: tleydxdy, so what prevets me from pointing a camera at the screen while I am viewing it?
11:24 pq: *prevents
11:27 tleydxdy: the tv sees you are doing that and stops showing you the pictute?
11:27 pq: the tv doesn't see my camera
11:27 tleydxdy: well then their camera system is crap
11:29 pq: the camera can be behind a half-mirror in a black box, or look like Mickey Mouse, or...
11:32 ccr: I think "eyes only" can only truly work for situations where both parties ('sender' and 'viewer') explicitly trust each other. for any DRM purposes it is a fallacy. if the content can be viewed, it can be copied - period.
11:32 pq: indeed
11:33 Company: pq: reddit comments mocking you for not knowing the screenshot tool prevent you from pointing the camera at the screen
11:33 pq: degrading quality during the copy is a thing though
11:34 ccr: of course.
11:35 ccr: and one can try all kinds of stop-gap methods to make it more difficult and slow things down, but alas ..
11:35 Company: if you do it well, Sam Altman won't use it
11:35 sima: dolphin, uh looks like lockdep splat in pci subsystem ...
11:35 sima: airlied, maybe backmerge?
11:36 sima: airlied, looks like it's 49de0dc87965079a8e2803ee4b39f9d946259423 we need
11:37 sima: which is only in 6.7 release sadly :-(
11:37 sima: still probably good enough excuse to make sure we can CI before sending the main pr to linus ...
11:38 dolphin: sima: wonder why it would impact only shards?
11:39 sima: dolphin, it's just a part of pci, maybe the others don't have that?
11:40 sima: I've seen the splat also in some bat machines I think, or I mislooked
11:40 sima: pci_bus_sem is the thing to grep for, and then it needs to hit some vmd_ functions and I think it should be a match
11:48 javierm: pq: yeah, the degrading quality part is why I said that more than "eyes only" is more like "receiver with the quality sent only"
11:49 dolphin: sima: AFAIK, the BAT and shard machines are not that different, maybe different Kconfig?
11:52 sima: dolphin, tbh not sure ...
11:53 dolphin: CI folks confirmed it's the same, so it just happens to not be touched by BAT, but most of the shard tests fail
11:53 dolphin: so each shard seems to hit it quite early
12:50 sima: pq, emersion daniels what do you think of output properties in atomic ioctl?
12:50 pq: sima, what are output properties?
12:50 emersion: OUT_FENCE_PTR?
12:50 sima: probably a new type, read-only, and you give atomic a list of these that are read back and stored into the userspace array after atomic_check has finished
12:50 sima: emersion, yeah but a lot more generic
12:50 emersion: what's the use-case?
12:51 sima: so we could give error reasons, hints, computed stuff like the output format and all that
12:51 sima: just randomly cross my mind rn
12:52 mupuf: sima: sounds useful for libliftoff
12:52 sima: so instead of the rather magic OUT_FENCE_PTR trickery it would be a lot more like normal properties
12:52 pq: javierm, HDR WCG displays probably do enough of quality degradation by simply displaying the picture alone. You'd need expensive camera to properly capture it, and even the picture has already been mangled for the display's panel, which would be less than optimal for any other panel.
12:52 emersion: that sounds useful, sima
12:52 sima: plus that added output-prop list in the atomic ioctl so you can get at them with TEST_ONLY
12:52 emersion: yeah
12:52 emersion: getting info out of the kernel via TEST_ONLY is important
12:52 javierm: pq: indeed
12:53 emersion: so user-space provides a list of output props it wants to query?
12:53 sima: kinda came up with this because trying to smash the current IMMUTABLE props we have for connector stuff like edid into the atomic framework needs some work anyway, and might as well do it properly ...
12:53 pq: sima, sounds really cool.
12:53 emersion: and the kernel fills that?
12:53 sima: emersion, yeah
12:54 sima: and since we make it a new property flag we could give it some clear read-only semantics and maybe some high level sanity checks on the implementation side
12:54 sima: instead of continuing to abuse IMMUTABLE
12:54 emersion: the thing i'm worried a bit about is in case the output value needs memory
12:54 emersion: user-space would need to allocate before-hand
12:54 sima: emersion, blob property
12:54 emersion: but might not know how much to allocate before-hand
12:54 emersion: hm, right
12:54 emersion: so kernel memory
12:54 sima: it gets a bit tricky though to make sure we don't leak them like a sieve
12:55 sima: like if we assing a blob prop id then it'll stay around until userspace nuked it
12:55 emersion: what is user-space's signal for "i'm done with it"?
12:55 sima: so if userspace doesn't know about a new blob output prop it might leak
12:56 emersion: user-space should only request props it understands
12:56 sima: DRM_IOCTL_MODE_DESTROYPROPBLOB
12:56 sima: hm
12:56 sima: we could do a weak reference trick
12:56 sima: since the kernel keeps stuff alive that's still referenced in the current state
12:56 emersion: ie, not request a prop which creates a blob and then not destroy it
12:56 sima: including keeping the blob prop id reserved
12:56 sima: so we could just put the blob in there like that
12:57 sima: and as soon as a new blob is put into the output blob prop, the old one gets garbage collected
12:57 sima: hm
12:57 sima: no
12:57 sima: doesn't work for TEST_ONLY, it gets garbage collected before the ioctl finishes :-/
12:57 pq: definitely "user-space should only request props it understands"
12:57 sima: emersion, I guess the rule would be a bit tricky, like we make it a weakly referenced blob
12:58 sima: but if userspace asks for it explicitly as an output prop in an atomic commit
12:58 sima: we upgrade it to a blob prop as if it has been created by userspace with DRM_IOCTL_MODE_CREATEPROPBLOB
12:58 sima: including all the lifetime and possible cgroups account rules
12:58 emersion: that sounds reasonable
12:58 sima: pq, yeah, but need some rules that work for this ...
12:59 sima: and if it's not requested as an output prop it's just like the boot-up state (for drivers with fastboot, e.g. i915 does create a mode blob this way)
13:00 sima: weak reference that's gone as soon as that state is gone
13:01 pq: sima, sound like you are thinking of kernel internals here - they confusee me. Why would a weak blob be created if userspace didn't ask for it.
13:02 emersion: yeah, kernel internals
13:02 sima: pq, mostly to keep the api consistent, since these things would work exactly like a prop
13:03 pq: UAPI?
13:03 sima: i.e. you could do atomic commit ioctl and then get prop ioctl, which seems to be the use-case for the actual_output_format one (or whatever it was called)
13:03 emersion: to me the easiest kernel API would not be blobs internally
13:03 sima: yeah from userspace
13:03 pq: umm...
13:03 emersion: like, it would be the blob contents struct instead
13:03 sima: emersion, it's a pretty simple way to get a pile of data to userspace
13:03 emersion: and then core DRM creates a user-space blob at the end of the commit if requested
13:03 sima: otherwise you get the entire 1. query size 2. allocate buffer 3. do the ioctl again dance
13:04 emersion: but drivers never deal with blobs directly
13:04 sima: emersion, oh yeah that'd be definitely how the internals would work
13:04 emersion: ah, then i don't understand the weak ref part
13:04 pq: oh, I didn't understand you wanted to use get_prop ioctl for these!
13:04 sima: I'm just talking uapi here
13:04 emersion: hm, get_prop?
13:04 sima: pq, it sounded like that's the plan for these hdmi output props ...
13:05 sima: might be that in the end we'll only ever use output prop list in the atomic ioctl together with test_only
13:05 pq: I thought you wanted to add a new pair of arrays to atomic commit ioctl, one array lists the output props to return and the other kernel writes the results into.
13:05 sima: pq, well that part is just to make it useful together with TEST_ONLY
13:05 emersion: my understanding would be that user-space passes a {prop_id, value} array to the kernel
13:05 sima: since the kernel otherwise entirely tosses that state and there's no way for you to get at it
13:05 pq: but why need get_prop ioctl support at all?
13:05 emersion: and then the kernel writes the values
13:05 emersion: without having to get_prop
13:05 sima: pq, it's zero code because it's all the same already on the kernel
13:06 sima: disallowing it would require code :-)
13:06 pq: sima, it cannot be zero code, if you have invent weak block refs or whatnot.
13:06 pq: *blob
13:06 emersion: (brb dealing with a ddos)
13:06 sima: pq, that's only complications in the atomic ioctl, and the added code would be for _strong_ refernces so the blob survives a TEST_ONLY atomic ioctl
13:06 pq: get_prop could just always fail on output props, or return always zero, or...
13:07 sima: the weak blob prop thing is already in use as I mentioned for fastboot state in i915
13:07 sima: also I think GETFB does a weak bo ref, same idea
13:07 pq: well, if you want to make get_prop ioctl work, okay.
13:08 sima: pq, weak referenced blob is essentially what you get if a) current atomic state refernces the blob and b) userspace called DESTROYBLOB
13:08 pq: but if atomic commit ioctl already contains the array where the kernel returns uint64_t results of the output prop queries, then I don't know why anyone would want to get_prop on output props.
13:08 sima: this is because people really don't like the RMFB semantics and much prefere CLOSEFB
13:08 sima: pq, yeah maybe no one
13:09 sima: aside from that seems to have been the plan for the hdmi output format props
13:09 sima: since they're set in commit, not in the ioctl, they're only guaranteed to be set when the drm event for that commit has come through
13:09 sima: for nonblocking
13:09 sima: so it's always a get_prop for that design
13:09 pq: oh
13:10 sima: but if we add output prop list to atomic ioctl, that's probably redundant
13:10 sima: (I don't like that design for a bunch of reasons, which is why I pondered what this should look like really)
13:10 sima: pq, other reason is that we could do it more incrementally
13:10 sima: 1. add output props, use them with get_prop ioctl
13:10 sima: 2. add more fancy output props that only make sense for TEST_ONLY, add the atomic ioctl complications
13:11 sima: incremental design and all that
13:11 sima: plus like I said, it's zero additional code to make it work compared to directly going atomic with output prop list
13:12 pq: except all the userspace code that needs to be written
13:12 pq: sound more complicated to me, but also not wrong
13:13 sima: we have very disjoint compositor space, so might not actually be real overlap there
13:13 sima: but yeah if userspace wants to go directly all the way, that's a good reason
13:13 pq: how could userspace not?
13:14 sima: well for props that only make sense to drive TEST_ONLY decisions, then yeah it has to
13:14 pq: userspace has to add the code to understand new props anyway
13:14 sima: I didn't look at what exactly userspace wants to do with the hdmi output format prop, but current code has no support for TEST_ONLY so seems not needed
13:15 pq: is the HDMI output format prop about RGB vs. 4:2:0 vs. 4:4:4 on the cable?
13:16 sima: yeah
13:16 pq: I guess the best use of that is to make sure you force it to remain the same when a compositor is taking over and wants a flicker-free boot, while having the option to force otherwise.
13:19 pq: Some people need to force things that drivers currently pick automatically. For backward compat a KMS prop to set that needs to have an "auto" value. But when it's "auto", you still want to know what the driver actually picked...
13:20 pq: ...so that if you are fine with "auto", you can tell the end user what they got, or if you want to enforce a value, you know what value is there already to avoid a modeset flicker.
13:23 pq: sima, if the atomic commit ioctl contains both output prop array and the return value array, it should also work when the commit lists no other props at all, used purely for reading output props.
13:25 sima: pq, yeah it'd also be a get_mutliple_prop ioctl I guess
13:26 pq: in TEST_ONLY mode at least
13:26 sima: pq, probably need to decide whether you're allowed to have objects in your output prop list that weren't in the input prop list
13:26 pq: oh?
13:27 sima: well if not we need to write a new impl because currently atomic duplicates states and would then read out the values from the duplicated states
13:27 sima: whereas get_prop ioctl reads the value directly from the current state
13:27 pq: That would forbid the purely reading case.
13:27 sima: so if we allow arbitrary output prop it needs a bunch more code
13:27 sima: not much, but it's not zero
13:28 pq: I think saving in implementation line counts is much less important than a clear UAPI. :-)
13:28 sima: pq, oh sure, just saying you don't get it for free, so needs actual usecase and tests and all that
13:29 pq: I never assumed any of that could happen without full-blows test and usersapce effort.
13:29 sima: pq, I mean the incremental addition of using TEST_ONLY + output prop list as a fancy get_prop ioctl
13:30 pq: adding a single output prop to be used with *any* UAPI needs the full test and userspace effort, right?
13:32 sima: yeah
13:32 sima: I thought you want to use this for state readout on compositor switch for existing props though?
13:33 pq: I didn't think of that.
13:34 sima: ah I guess I misunderstood what you meant with taking over and flicker free boot
13:35 pq: that was specific to the HDMI color format prop
13:35 any1: This is only mildly relevant to the current discussion, but do you guys have any thoughts on this? https://lore.kernel.org/dri-devel/CAFNQBQyg+yXSJRtZtyHXMfyBOYrQpU0R0XFUJLcof9rakrBYQA@mail.gmail.com/
13:36 pq: sima, but now that you mentioned, if the same call can be used to read out everything, that would be cool. OTOH, being a new feature, userspace cannot lose the old code for quite some time.
13:37 sima: any1, it's pretty much directly relevant since output props is the generic way for drivers to tell userspace about all kinds of things
13:38 sima: any1, meaning this idea was motivated by pondering your patches
13:39 any1: Well, they're really Werner's patches. I just rebased them and fixed the i915 implementation. :)
13:45 pq: any1, I think the best way to deal with the combinatorial explosion with format/mode/bpc props is to avoid having to generate all combinations. I guess most of them can have a "auto" setting, also in UI, and then separate show what you would get.
13:46 pq: what you would get would be queried from the driver
13:46 pq: then if people want to force some aspects to specific values, they can change "auto" to something else in the UI, and see how the driver responds.
13:48 any1: pq: That sounds like the current approach.
13:48 pq: when the user opens a drop-down of possible values for one prop, the UI could probe the driver for all those values in order to tell the user which ones are possible with the currently selected values for all the other props
13:49 sima: yeah for gui interfaces the current test_only should be enough since users can't change more than one value at once
13:49 sima: so there's no combinatorial explosion to test
13:50 pq: any1, I have a hard time imagining anything else, given the fully exploded list of all driver-possible combinations would still be too long.
13:50 sima: the trouble is with compositors where you don't have a human who can just play around with stuff to get an intuitive feel for constraints
13:50 pq: If the end user is fiddling with these, they know which prop is most important to them, and can fix that first, and see what's left with the others.
13:51 sima: yeah
13:51 sima: also with gui there's no "must draw next frame in 5ms" constraint
13:51 pq: Well, a compositor is not very different: a compositor has its own policy of which prop is most important to maximize first, then pick what's left of the rest.
13:52 pq: This is only needed on mode switch, too, so performance is not *that* critical.
13:53 sima: pq, well I meant for the more general kms config problem, picking the right plane config for a given scene is rather hard
13:53 javierm: sima: for compositors that don't have an human to play around, that will mostly be embedded / vertial integrated products where the constraints will be mostly fixed I guess?
13:53 any1: I was just thinking that since color format is a per-mode capability, it might be good idea to send it with the mode info.
13:54 sima: any1, shared output clocks can break your assumption
13:54 sima: so you still cannot rely that if an output format is in the mode_info that it's guaranteed to work
13:54 sima: only that there is _a_ possible kms config where it's possible
13:55 any1: sima: But at least you know up front what's _not_ going to work.
13:55 pq: javierm, and all the usual desktop compositors too, because most people do not want fiddle with trivialities.
13:55 javierm: pq: right
13:55 javierm: hence your comment on 'auto'
13:55 sima: any1, doesn't help you in your gui selection box, because you still need to TEST_ONLY verify against the current config
13:56 sima: unless you want to piss of userspace by showing stuff that doesn't work in the drop-down list
13:56 pq: well, "auto" is good for most end users too, but it's also needed for UAPI backward compat as the default value for the prop.
13:56 sima: *piss off users
13:57 sima: any1, so you need TEST_ONLY anyway, and at that point you don't really need the flags in mode_info since it's purely redundant info
13:57 any1: That's a fair point
13:59 sima: any1, now where current atomic test_only breaks apart is if you want to change a lot of props and then figure out what's possible
13:59 sima: that's where the output prop list idea comes in, so you can ask the kernel what a good value would be for an entirely different config
14:00 sima: but incremental changes in gui should be fully covered as a use-case
14:00 pq: sima, I didn't realize you wanted to tackle that biggere problem as well.
14:01 sima: pq, well we've been talking about it since forever and been pondering what could error/hints for TEST_ONLY failures look like since years ...
14:02 pq: sure, but I failed to connect that to output props properly.
14:02 pq: I see the mechanism working, but defining the actual output props to help with it seems difficult.
14:03 sima: pq, fully agreed
14:03 sima: but maybe starting with a smaller problem might get this going
14:05 pq: for failure feedback, I wonder if there should be a kernel-writable array matching the KMS props that are being changed, in order to return hints which props were disliked and maybe even why.
14:05 sima: pq, but I think it might help with a lot of the detail issues, like if the hw needs a tiny bit of rounding in plane coordinates, or a bit of fiddling with gamma ramps and all these might be doable in failure simple and well-contained output props
14:05 sima: pq, yeah that's where the discussion usually landed, but I feel like that's too big
14:06 sima: so maybe adding incremental output props for more specific issues is a more tractable approach to get somewhere
14:07 pq: it feels really difficult to define output props for failure conditions, especially if userspace needs to explicitly ask for each output prop to be returned.
14:07 agd5f: robclark, Do you know anyone on the gmail team? Can you figure out why gmail seems get so many bounces? Lately I get unsubscribed once or twice a week from freedesktop MLs due to excessive bounces and as the amd-gfx admin, I get get tons of emails that list members with gmail addresses are also getting disabled due to excessive bounces.
14:07 agd5f: only seems to affect gmail
14:08 sima: agd5f, maybe #freedesktop?
14:09 sima: pq, could also be more meaningful, e.g. there's often constraints between features
14:09 agd5f: sima, I asked there yesterday, they checked the logs and it seems gmail no longer plays nicely with mailing lists
14:09 sima: like where a given format is incompatible with rotation, and changing either would help
14:09 sima: agd5f, ugh :-(
14:09 zamundaaa[m]: pq: whether or not a property is "at fault" for the commit failing sounds a bit difficult to define too. If it needs too much bandwidth, it would have to complain about most plane properties for example
14:10 sima: zamundaaa[m], yeah there might also be rather general "oversubscribed on planes, use less" issues
14:10 pq: zamundaaa[m], yes, bandwidth is like that.
14:10 sima: or "oversubscribed on memory bw"
14:10 sima: I think some of them are well defined enough that compositors can then do meaningful stuff with it
14:11 pq: I guess we should ask: what kind of feeedback would let userspace do better, rather than what actually went wrong.
14:11 sima: pq, yeah
14:11 MrCooper: agd5f: #freedesktop is still better to discuss that, the relevant people are unlikely to notice it here
14:11 agd5f: sima, I'm guessing gmail is lowering sender reputations due to too many recipients or something like that. Maybe this is the end of mailing lists
14:11 sima: like for pure memory bw it's pretty easy for userspace to figure out how to cut it
14:12 MrCooper: the end of using gmail for mailing lists, maybe
14:13 agd5f: like the email lists get really low sending domains because it's assumed that mailing lists are spam
14:13 agd5f: *low reputations
14:14 sima: any1, can you pls summarize the discussion/conclusion here on-list?
14:15 any1: sima: I think you're probably in a better position to summarise than I am, since you have a full understanding of it. :)
14:16 sima: any1, uh I just jumped over that thread because "explained it on irc" :-)
14:17 any1: This is my first foray into the DRM subsystem.
14:18 javierm: any1: IME re-reading these kind of IRC discussiones and trying to come with a summary is a very good learning experience :) It's OK if there are misunderstandings in your summary since Sima and others can chime in
14:18 javierm: *discussions
14:19 sima: any1, if you want you can pastebin the draft here for quick review
14:20 any1: sima: When you say "So I think the better approach would be to put the output type into drm_connector_state", by "output type" do you mean the "active color format"?
14:20 sima: any1, yeah
14:21 sima: any1, but that's the big fancy output prop idea (at least a first step towards that), I thought the irc conclusion here was that TEST_ONLY should be good enough for gui config tool usecase?
14:22 sima: airlied, ah just seen your drm-next PR, I guess that makes the backmerge obsolete
14:22 any1: sima: Ahh, ok, so we're back to dropping "active output format" entirely?
14:23 pq: sima, TEST_ONLY that can answer "what would the driver have picked for this prop that I set to auto?", then yes.
14:23 sima: any1, yeah it sounds like you don't really need it?
14:23 any1: Well, except some people have pointed out that the user might want to know what was picked if they selected "auto"
14:24 pq: there are two separate use cases here
14:24 pq: people playing with setting UI would like to know what "auto" would result in, but that's just nice to have
14:25 pq: the other use case is the flicker-free boot into known configuration I mentioned
14:26 pq: the former need TEST_ONLY feedback, the latter is happy with the old get_prop is there if a prop that tells us
14:26 pq: *if there is
14:28 any1: It's currently possible to continue with the previously set property?
14:29 pq: sure
14:29 pq: The precedent for the flicker-free boot is "max_bpc" prop which is actually a little different than what was discussed here. It has no "auto" setting, but it still acts as a limiter.
14:29 pq: so the actual bpc picked can be lower
14:30 any1: Cool. Then we don't need "active color format". :)
14:30 pq: drivers may initialize with different values for max_bpc, so userspace needs to read it before programming it
14:30 pq: well, people still want to know what the driver actually chose
14:30 pq: some people
14:31 any1: Those people can get an HDMI analyzer for $500. :D
14:31 pq: the problem with "auto" is that any mode set could make the driver decide differently, so if you want to keep your format, you cannot rely on "auto"
14:32 any1: hmm, yes
14:34 any1: I'll try to write a summary some time today.
14:34 zamundaaa[m]: The UX problem with "auto" is really that if the user has a problem with their screen, they first have to trial and error the other options because they don't know what's currently beinh used
14:35 zamundaaa[m]: We have the same problem with broadcast rgb and we have one or two bug reports about that
14:36 zamundaaa[m]: But waiting with fixing that until we have output properties for commits, and then adding an output property that says what the driver would recommend / choose with "auto" would probably be okay. As long as we actually get that eventually
14:43 robclark: agd5f: sorry I don't.. and it's a pain, it's happening to me too
15:47 any1: Was there a conclusion regarding resource management for output property blobs?
16:14 any1: sima: https://gist.github.com/any1/f67b3ee48b7ef73460f56f7769267c9b
16:18 gpiccoli: Hi folks, this could be an old question..but here it goes (apologies if obvious): why efifb doesn't work after S3/deep sleep? It seems to be restored fine after s2idle, though during s2idle the screen is effectively "powered-up", I can see its backlight on...
16:19 gpiccoli: On S3 it power-offs fine, screen is disabled, but never comes back. Would the display need to be reprogrammed (like it is on boot time by the UEFI GOP) after S3 ?
16:28 sima: any1, thanks a lot, lgtm
16:28 sima: any1, I guess the part that's missing is that for gui config selectors current TEST_ONLY should be enough and we don't need any of these more fancy things we discussed
16:29 sima: that was really the main reason why I asked you to summarize since that's the question you jumped into the discussion with
16:30 sima: tzimmermann, we generally don't take -next pulls during the merge window, only -next-fixes for the current one ...
16:30 tzimmermann: sima, oh sorry
16:31 tzimmermann: sima, maybe just wait until -rc1
16:31 tzimmermann: i promise to do better
16:31 sima: tzimmermann, no worries, just wanted to tell you if you'll wonder why it's not landing
16:32 sima: the "-next never closes" is kinda more for committers' benefit, to avoid them pushing new features into the merge window
17:11 agd5f: gpiccoli, on S3, the GPU usually loses power. on s2idle, it generally just gets put into a low power state
17:47 gpiccoli: Hi agd5f , thanks - indeed that makes sense. But I thought efifb was basically a memory region set/mapped, different from the full gpu works ...
17:47 gpiccoli: so, even this in this simple mode, we'd require reprogramming?
17:53 javierm: gpiccoli: but same could be for the display controller or any needed clocks, regulators, etc
17:54 agd5f: gpiccoli, sure, but the GPU points to it and you need to program the display hardware to actually scan it out
17:54 gpiccoli: oh yeah, I just had a wishful thinking here..that for a simple fb that would be simpler haha
17:54 gpiccoli: this was due to my narrow understanding of how GPUs work..certainly! Thanks a bunch javierm and agd5f for the clarification
17:55 gpiccoli: The good point: amdgpu_fb works fine after S3, so amdgpu reprograms everything..so not a biggie not having efifb [I'm testing something with amdgp blacklisted, that's the full context heh]
18:01 agd5f: I doubt S0i3 works fully without the GPU driver loaded. I don't think the firmware will enter the lowest power state without the driver driver setting up a bunch of power features
18:14 gpiccoli: interesting...
18:15 gpiccoli: it apparently works, but I'm not measuring power ... so it maybe be suboptimal despite appearing to work heh
19:18 karolherbst: agd5f: well.. core pci can runtime suspend GPUs just fine (mostly)
19:18 karolherbst: it's just not enabled by default
19:35 agd5f: karolherbst, depends on the device
19:58 karolherbst: yeah, fair
21:57 jenatali: Is it expected to get a Gallium resource_copy_region call where the source and dest have wildly different formats?
21:58 zmike: there's a util function for determining copy_region compatibility
21:58 zmike: I'd read that
21:58 jenatali: That I'm supposed to call within the driver? Or that mesa/st should call?
21:58 zmike: in the driver
21:59 zmike: you would e.g., call this at the top of blit() and then just call copy_region instead of blit if compatible
22:00 jenatali: Right, I'm not getting a blit though, I'm getting a copy
22:00 zmike: yeah I'm just giving an example of the usage
22:00 jenatali: Yeah it seems like gallium should be giving me a blit though, unless it's expected that I can internally route in both directions
22:01 zmike: I don't think that's expected, no
22:06 airlied: maybe if the wildly different formats are in the same class
22:06 jenatali: RGBA16 vs RGBA8
22:06 airlied: seems wrong then
22:07 airlied: unless they have different pitches maybe
22:07 jenatali: Cool. Sounds like I should get an apitrace and file an issue then
22:07 airlied: it should just operate like a memcpy
22:07 jenatali: Right
23:12 jenatali: Oh cool this app crashes apitrace
23:14 jenatali: Oh nvm, my fault
23:19 jenatali: Ok so it looks like the app is trying to redefine a texture that was RGBA with UNSIGNED_SHORT and mips, to RGBA with UNSIGNED_BYTE and no mips, and Mesa seems to be trying to copy the RGBA16 mip data into the new RGBA8 texture
23:33 robclark: possibly fallback path for something the blit path doesn't support?
23:35 jenatali: Looks like I'm broken by https://gitlab.freedesktop.org/mesa/mesa/-/commit/06b526de0565d5485a2111e3901bd5824ead4314
23:35 jenatali: Mesa thinks the texture is mipmap complete because the internal formats are both RGBA, despite one being RGBA16 and the other RGBA8
23:43 jenatali: Ok I think it needs to be both TexFormat and InternalFormat matching