00:28 andreasbackx: I'm using zwlr_screencopy_frame_v1::copy to copy an output's frame into a buffer and then subsequently am creating a new wl_surface to which I am attaching the buffer to. Though if the output is in portrait mode, then it seems like the buffer does not take this into account? Not applying any transforms will make the buffer show rotated when committing. Though leveraging
00:28 andreasbackx: set_buffer_transform with the value of the wl_output transform will "cover" the output and stretch it, not rotate it as desired. Do I have to manually rotate the buffer I am getting from screencopy?
00:37 soreau: andreasbackx: it probably depends on what compositor you're using. If it doesn't do The Right Thing for you, then you might have to fix it up
00:43 andreasbackx: soreau: testing this on Hyprland. Trying to give it a shot in a nested Sway window, if I can figure out how to make it open a terminal in there as Hyprland swallows my commands...
00:45 andreasbackx: And I realise I cannot easily test it this way because that nested window is not rotated...
00:47 andreasbackx: Oh, it seems to name it WL-1 so I can force a transform, nvm.
00:49 andreasbackx: It seems like it's a Hyprland issue, Sway seems to handle it correctly. Thanks for the hint.
00:49 soreau: np
11:07 pq: FYI, five years ago I would have personally NAK'd hard any proposition to bring output-relative or absolute positioning in an extension, but nowadays it seems practically all wayland-protocols members have embraced the "Wayland desktop paradigm", so I can actually be more honest about the options and let the community make decisions. My opinions are still the same, just less vocal and absolute. :-)
11:22 psykose: that kind of positioning was a gigantic pet peeve of mine (in how much i hated it) back in xorg days..
11:22 psykose: at least nowadays it seems like there would be way more semblance of control :)
11:30 pq: the desire for the old days still lives strong
11:45 bl4ckb0ne: next is wleyes!
11:50 emersion: ah, the classic "i hate wayland, my workflow heavily relies on xeyes"
11:51 daniels: the good news is that xeyes still works as well as it ever did
11:52 pq: ...that is, over any X11 window? :-)
11:53 daniels: right, or in a native X environment
11:53 kennylevinsen: legally mandated xkcd reference: https://xkcd.com/1172/
12:00 pq: a native X environment can only have X11 windows, so of course
12:24 emersion: daniels: thanks for replying to this thread! so you think "both devices are platform" is a check which should always be enough?
12:24 emersion: what is same-bus exactly?
12:42 daniels: emersion: I think so, yeah
12:43 emersion: a bit worried about someone coming up with new hw where the rules are more complicated
12:43 daniels: same bus as in, both devices are platform is always fine (that’s how it’s designed right?), both PCIE should be fine (high bandwidth), both USB should be fine (you’re copying anyway so there’s no fallback)
12:43 emersion: but i suppose we can always improve the logic then
12:44 emersion: both PCIE i wouldn't do it
12:44 daniels: but if you’re mixing, say, USB and PCIE, then maybe you should be treating as more indirect
12:44 emersion: both PCIE i'd use a shadow buffer
12:44 daniels: sure - if we’re down to that as the biggest problem then we’re doing well :) I’d happily agree to the
12:44 daniels: *to that
12:44 emersion: for both platform i don't use a shadow buffer, i render directly to the scanout-capable buffer
12:45 daniels: I think the important thing is not baking dumb stuff into the API, letting us experiment with reasonable semantics and tweak them, then establishing that as the standard
12:45 emersion: basically, my main question is whether the both-platform heuristic is good enough, or if we need something like mesa's allow-list of drivers
12:45 daniels: (both platform - yeah, the hardware is designed that way right, so they very well should work together …)
12:45 daniels: I think that works
12:46 emersion: well, i can see someone coming up with a weird SoC with 2 display chips and 2 render chips and 2 memory banks
12:46 emersion: after all, i have a PCIE card in my drawer, with 2 GPUs baked in
12:46 daniels: hnngh
12:47 daniels: I haven’t seen separate display ever; i have heard of exactly one vendor who’s doing two GPUs and one who’s considering it
12:47 daniels: but the former is niche and the latter i think won’t do it
12:47 emersion: two GPUs but how is the memory situation?
12:47 emersion: can both GPUs render to the display device memory without being slow?
12:48 emersion: well, at some point, we'll really need buffer allocation constraints :P
12:48 daniels: yeah because they don’t have dedicated RAM anyway - it’s all system memory
12:48 emersion: cool
12:49 emersion: tbh i really like the "same platform" logic, because it lets me figure out a choice before i need to instanciate Vulkan/GL
12:50 daniels: srsly :)
12:51 emersion: the only remaining meh thing is that i still need to create a gbm_device for the display-only device, and then rely on mesa's kmsro to allocate a dumb buffer
12:51 emersion: but that's mesa internals so w/e
12:53 emersion: maybe i'll try migrating that to dma heaps for a driver some time
12:53 daniels: yeah, avoiding gbm creating a gallium driver instance would be great
12:54 emersion: if we have "use dma heaps" or even "use dumb buffers" in loader…
12:54 emersion: we could just Do The Thing in GBM
12:59 daniels: very true! and realistically, most of what we need is a dumb-buffer alloc flag where we can just query the stride for the allocation instead of actually making the allocation
13:00 daniels: then heaps are usable and \o/
13:00 pq: daniels, what did you mean by "any non-integrated display controller (at least any that you'd use with a GPU) isn't going to have local memory"? Discrete controllers would always have local memory for scanout, no?
13:01 pq: or does "integrated" here mean that the GPU and the controller are on the same chip?
13:01 pq: I mean, essentially same IP
13:11 daniels: errr, i meant integrated there i think
13:34 wlb: weston Issue #820 opened by Marius Vlad (mvlad) Overlap output for RDP as a secondary backend https://gitlab.freedesktop.org/wayland/weston/-/issues/820
14:01 leandrohrb5: daniels emersion: whould make sense sharing this device pair matching logic between egl and this vk extension in the future?
14:02 emersion: with the direction we're heading in, vk wouldn't really need it
14:02 daniels: right
14:02 emersion: modulo VK_KHR_display maybe?
14:02 daniels: meh
14:04 emersion: yeah, meh
14:06 leandrohrb5: ok cool!
15:20 swick[m]: pq: ISO 22028-1 reminds me a lot of Digital Color Management: Encoding Solutions
15:20 swick[m]: nice, succinct summary
22:12 tutitutututu: They just calibrated me in Cambodia , it appears that everyone around me have high blood pressure issue, this is caused my bacteria, so high intensity signals cause that bacteria to grow in numbers in human guts, causing a higher blood pressure , they mess around with cell towers, so most people around me their organism can not fight back , there has been complications to focus that lethal energy at me due to random friends getting
22:12 tutitutututu: health issues, however my organism seems a tough nut it has brilliant flexibility and immunity response, you can not find more ideal numbers by default. I am like hg in temperature sensing glass, ideal numbers, some tests they perform considering that. I got bacterial poisoning and 4+ maximum to the point where my hearts left valve started to hurt, just like the medicine normally diagnoses the biggest danger of that, and this was
22:12 tutitutututu: deliberately designed, i did miraculous recovery out of that too one more time. e.coli bacteria is normally the cause of high blood pressure, however i had staphylococcus , but to the amplified signals they behave the same. signals at certain intensity levels behave like culturing medium. It's not like i prepared to kill, but i likely have to, these rats are very high end abusers after me. So far they have miserably failed indeed
22:12 tutitutututu: though, but caution and contra attack with such is compulsory.
22:13 bl4ckb0ne: hi tutitutututu
22:13 bl4ckb0ne: you're off topic
22:14 Ermine: bl4ckb0ne: aren't you op?
22:14 bl4ckb0ne: nope
22:26 tutitutututu: I am just helping you , it appears some world rulers or powers or some type of gang has been tried to prepare for massacre, i already have cracked the performance related code my own though and i am graduated from a research.
22:53 bl4ckb0ne: and how is that involved with wayland