00:39karolherbst: "Sampler-less reads differ from reads with sampler."
00:41karolherbst: ahh yeah, hw is unhappy
00:42karolherbst: but seems like only 1Dbuffer is busted
01:35karolherbst: uff "Image Dimension test failed. image width = 1024, image height = 1" :/
01:39imirkin: buffer usually implies backed by a buffer resource rather than a texture resource
01:39imirkin: and regular sampling doesn't work on these
01:39imirkin: you have to use the equivalent of texelFetch()
01:39karolherbst: mhhh sure
01:39imirkin: a regular texture() type op won't work
01:39karolherbst: yeah, maybe that's what's going wrong
01:40imirkin: (not just because it's not defined in GLSL, but also because the hw won't be happy)
01:40karolherbst: I think OpenCL allows sampler ops on imagebuffers
01:40karolherbst: let me check
01:40imirkin: right. so with a sampler, you do texture()
01:40imirkin: without a sampler, you do texelFetch
01:40karolherbst: but I thought on a buffer backed image/texture we can't use samplers
01:42karolherbst: ahh "The built-in function calls to read images with a sampler are not supported for image1d_buffer_t image types."
01:42karolherbst: okay.. then the test is doing something dumb or we are
01:43karolherbst: but maybe the test is creating an image1D and image1DBuffer object but copying in the same memory or so
01:43imirkin: buffer-backed images can't do sampler-ful reads
01:43imirkin: texelFetch doesn't consume a sampler
01:43imirkin: (well, it kinda-sorta does, but for srgb decoding iirc?)
01:43imirkin: (and that's a nvidia hw quirk)
01:44karolherbst: the test tells me " Sampler-less reads differ from reads with sampler."
01:44karolherbst: but maybe that's with plain 1D images?
01:44karolherbst: but 2D and 3D are not causing any issues
01:45karolherbst: imirkin: I think OpenCL expects "CL_FILTER_NEAREST - CL_ADDRESS_NONE - UNNORMALIZED" behaviour from samplerless reads
01:45karolherbst: oh well..
01:46karolherbst: that will be fun to debug
01:46karolherbst: but for now I am more concerned about this failure: "Image Dimension test failed. image width = 1024, image height = 1"
01:46karolherbst: works for 512x1
01:46karolherbst: and smaller
02:31karolherbst: ehh.. that was the CTS being stupid
07:25shfbsdbvf: Hi, few days ago I asked here about reporting bugs and was adviced to use validation layers. I have only one layer from repositories - VK_LAYER_KHRONOS_validation and it showed 2 error: "[UNASSIGNED-CoreValidation-DrawState-NoActiveRenderpass] No active render pass found at draw-time in VkPipeline" and "[VUID-vkCmdDrawIndexed-renderpass] This call must be issued inside an active render pass. The Vulkan spec states: This command must only be called inside
07:25shfbsdbvf: of a render pass instance".
07:25shfbsdbvf: Maybe I should add other layers to get more information? Could you please tell me which ones?
07:26shfbsdbvf: and with what options in vk_layer_settings.txt
08:11airlied: shfbsdbvf: why do you need more info? those errors are prettg bad
08:16shfbsdbvf: to report a bug
08:16shfbsdbvf: airlied: I'm not sure how I should report it
08:17shfbsdbvf: It's in unreal engine and if developers want to reproduce it they'll need ~100gb of free space and few hours to build it
08:17shfbsdbvf: maybe I should make a minimal c++ program that reproduces this bug?
08:18shfbsdbvf: also now I'm not sure if UE used vulkan api properly. It can be the case when api is used incorrectly, right?
10:20shfbsdbvf: I'm not sure where exactly the bug is because it works on nvidia but doesn't work on amd
11:25jekstrand: shfbsdbvf: Those two errors sound pretty serious
11:26jekstrand: shfbsdbvf: It's definitely a bug in either your code or Unreal.
11:27jekstrand: shfbsdbvf: I'd be very surprised if Unreal is making that error on its own. Likely you're either running an ancient version or doing something wrong on your end.
11:36FLHerne: shfbsdbvf: To be clear, if the validation layers raise warnings your application is definitely using the API incorrectly
11:37FLHerne: (or the validation layer has a bug, but that seems unlikely given that the app doesn't work properly anyway)
11:38shfbsdbvf: FLHerne: so I should report a bug in UE?
11:41shfbsdbvf: Maybe I should try more detailed logs? Like api_dump layer?
11:41shfbsdbvf: Just not sure because it works with other gpu
11:46shfbsdbvf: jekstrand: just checked in 4.26 and the bug disappeared, thanks for your suggestion
11:48shfbsdbvf: Hope the second bug disappeared too
11:50jekstrand: shfbsdbvf: What version were you on before?
11:50jekstrand: That's pretty recent too. Weird.
11:50shfbsdbvf: Actually it was an old 4.25
11:51jekstrand: Trying to draw without a renderpass is a pretty serious bug. I'm honestly a bit surprised it worked anywhere.
11:52shfbsdbvf: Maybe nvidia's vulkan correct common mistakes?
11:52shfbsdbvf: Or something crashed before that call
11:53jekstrand: I doubt it's correcting mistakes.
11:53jekstrand: It's probably doing the wrong thing just not in a way that crashes.
12:02shfbsdbvf: Yes, second bug also disappeared
12:03shfbsdbvf: In 26
12:03FLHerne: -preview-6 sounds like some kind of beta release?
12:04FLHerne: I expect it was fixed before 4.25 proper
12:06shfbsdbvf: Then I guess I should build stable 4.25 and check there, because 4.26 is also -preview :)
12:07shfbsdbvf: But it won't be fast. Thanks for your help :)
13:47Darxus: I think rebooting yesterday, with an update from the oibaf ppa (mesa, etc.), broke my world of warships (steam / proton / mesa). Then doing the same today in an attempt to fix it, broke everything else in steam. Is there a better place to see if others have had similar experiences?
15:41DPA: I've now fixed the issue I had with etnaviv+mxsfb with applications which didn't use modifiers (MR !7307). It turned out not to be the modifiers this time.
16:28karolherbst: DPA: I wish we could do such hacks L.
16:29karolherbst: the painful issue we have with tegra is that we can't render into linear depth buffers
16:29karolherbst: but I think you are creating a shadow copy for that, no?
16:37DPA: karolherbst: I think so, but I'm no expert with this code base yet. Also, I think this may somehow be related to my Xorg issue #1083.
17:36karolherbst: daniels: congrats to your public statement and declaring the end of Xorg :p
17:45daniels: karolherbst: ??
17:45karolherbst: I meant danvet_
17:46daniels: I still feel like I'm missing something, heh
17:48karolherbst: one phoronix article gets comments quite quickly :D
17:48karolherbst: and it's about "X is abondoned"
17:48karolherbst: it's a bit wild
17:49karolherbst: even for phoronix 110 comments after 8 hours is a lot
17:49emersion: phoronix being phoronix as usual
17:49karolherbst: well, it's true though :p
17:49karolherbst: I am more annoyed by the users saying "but X isn't.... "
17:50emersion: clickbait clickbait
17:50HdkR: It doesn't need a release when the software is complete </s>
17:51kisak: I needed to look up the definition of abandonware since it doesn't match quite right, the article presents a half truth
17:52danvet_: karolherbst, I'm proud
17:54bnieuwenhuizen: makes me think what happens with stuff people are still contributing though. Like the recent VRR support for modesetting
17:55karolherbst: they are free to do so
17:55karolherbst: but I think it should be clear that "wayland" should be the default and the future
17:55karolherbst: thre is still legacy software around being X only anyway
17:55karolherbst: and maybe xwayland can make use of that VRR stuff?
17:55bnieuwenhuizen: I'm more wondering is why are we adding X11 features if there is not going to be a new release ;)
17:56karolherbst: beats me
17:56karolherbst: who wants to do the next Sorg release? :p
17:57bnieuwenhuizen: no clue. On the other hard from previous discussion I thought the main problem was the core of the Xserver and that is something you also have with a Xwayland only release
17:57karolherbst: nope, the problem is, that there isn't anybody willing to do the release :p
17:57karolherbst: and nobody showed up wanting to do that
17:58karolherbst: so, no xorg releases
17:58karolherbst: but I guess remving the Xorg server binary is probably the best approach anyway
17:58bnieuwenhuizen: I wonder if we should just put it on autopilot and release automatically
17:58karolherbst: and then we still need somebody who creates the release
17:58bnieuwenhuizen: I mean, for most mesa drivers that is essentially what happens anyway
17:59karolherbst: but Xorg is a bit more restrictive here
17:59bnieuwenhuizen: what is the restriction?
17:59karolherbst: well, for mayor releases it's probably fine, but minor can't break the ABI and stuff
18:01bnieuwenhuizen: you can throw the browser model of everything is a major release (+ probably patch releases that are cherry-picked by the occasional dev that wants to, fully self-service style)
18:01karolherbst: and how is responsible in case something bad happens?
18:02karolherbst: but anyway, the question is still _who_ wants to take care of all that
18:08kisak: sounds like there's some assumption that there's a pre-release quality control phase that has existed in the past and must continue. It is possible to go backwards in terms of quality control if that's what's required to move forward
18:09bnieuwenhuizen: that was pretty much the idea I was thinking of yes
18:09bnieuwenhuizen: can't be hard to configure gitlab to just create a tag every 6 months
18:10linkmauve: I’ve been running Xwayland master as my daily driver for some years already, and so far I haven’t experienced any bug that wasn’t also present in 1.20 Xorg when I tested that.
18:11exit70[m]: [random stupid user] do you get accelerated glx?
18:14exit70[m]: cool. i guess not using nv binary driver? disclaimer: the company i work for use nv cards for workstations
18:14bnieuwenhuizen: nvidia + Xwayland not have gfx accel is a known issue
18:16emersion: nvidia proprietary driver not playing well with the rest of the ecosystem is a known issue
18:17linkmauve: exit70[m], I almost exclusively use Intel.
18:18linkmauve: If your company doesn’t disable the Intel GPUs, you can use that as the GPU, and use Nouveau only for its DRM connectors.
18:19exit70[m]: no igpu on xeons?
18:20dcbaker[m]: exit70: not in any current ones I think
18:21kisak: bnieuwenhuizen: considering the pace of development, auto branching + tag once every year might be a better pacing. Then if there's an issue significant enough that it needs a follow up, then deal with it as needed (thinking the oddball CVE that gets triaged every now and then)
18:22exit70[m]: anyhow i'm a small fish in a big corp. if the message on the issue is loud and clear maybe there is hope.
18:29daniels: karolherbst: oh dear ...
18:34karolherbst: kisak: next question: who wants to be responsible? :p
18:34karolherbst: we can discuss the technicallities all we want, if there is nobody stepping up and being the maintainer, then it won't happen
18:40airlied: danvet_: nice!
18:41emersion: i wouldn't mind allocating some time for an xwayland release, but not for a full xserver release
18:42bnieuwenhuizen: I think my question that started the discussion between me and Karol, what makes a xwayland release "easier"?
18:42airlied: yeah i thunk an xwayland only release isnt a problem
18:42airlied: bnieuwenhuizen: no abi
18:42airlied: and no regressions
18:42emersion: also code i can grok
18:42karolherbst: emersion: that's what everybody is saying :p
18:42bnieuwenhuizen: why no regressions?
18:42airlied: because it has been tested
18:43bnieuwenhuizen: and the rest hasn't?
18:43airlied: pretty muxh
18:43emersion:runs xwayland master all the time
18:43karolherbst: bnieuwenhuizen: you are free to step up and be the new xorg maintainer if you wish to create a release though
18:44airlied: really if 1.21 got out the door and was horrible it might help set the stage for a new strategy :-p
18:45karolherbst: anyway, what are the biggest reasons people still prefer using X instead of wayland?
18:46karolherbst: besides the obvious "desktop is broken" and "misses features (*cough* network transparency bullshit *cough*)
18:46exit70[m]: i think i mentioned one: glx on nv hardware
18:46airlied:likes the log file :-p
18:46karolherbst: yeah well... that's not our problem :p
18:47karolherbst: and nvidia would be preasured playing nicely if we just say: "X is over, no support, all bugs closed"
18:47DPA: ssh -X, I like xfce, I like my own WM (easier than writing a compositor), etc.
18:47bnieuwenhuizen: so, personally, window manager is not ported yet, but also hearing a lot of stuff like screensharing doesn't really work
18:47airlied: and ajax is trying to fix glx
18:47emersion: DPA: https://gitlab.freedesktop.org/mstoeckl/waypipe/
18:47karolherbst: bnieuwenhuizen: you misspelled "isn't implemented"
18:48bnieuwenhuizen: karolherbst: the fun is there are options now via pipewire
18:48karolherbst: but that's the reason X is just insecure
18:48emersion: i screenshared my wayland desktop for XDC
18:48karolherbst: bnieuwenhuizen: sure, but the compositor is in control and deny requests, etc..
18:48karolherbst: *and can
18:48bnieuwenhuizen: but wayland is a smaller core and the ecosystem reality is that outside of the core things are still somewhat fragmented
18:48bnieuwenhuizen: and that is biting users
18:49airlied: but i expect since there are still a lot of interest in X.org
18:49karolherbst: but I don't see this progressing really except for a small group of people
18:49airlied: thee should ve no problem finding an rm
18:49karolherbst: and everybody else is still "X is the thing"
18:49karolherbst: I think most of the problems really come from not deprecating X officially
18:49bnieuwenhuizen: and not saying it can't be fixed, but a random user is not really motiviated to make their setup work with wayland
18:49ccr: as long as I can't have (near-) identical UX experience vs. window manager I've used since 1998, I can't really bother to even try.
18:49karolherbst: bnieuwenhuizen: desktop devs are not motivated enough, that's my biggest problem
18:50karolherbst: why do we still have just one desktop which is useable with wayland without running into stupid bugs?
18:50emersion: ccr: which WM?
18:50ccr: emersion, WindowMaker :)
18:50karolherbst: somebody needs to port it over to wayland then :p
18:51emersion: bleh, can't find a window maker clone in that list https://github.com/swaywm/wlroots/wiki/Projects-which-use-wlroots
18:51ccr: I think the librarifying of wayland compositor stuff needs to advance further before wider re-implementation of X WMs will occur
18:51emersion: … and we do have some pretty crazy stuff in here
18:51bnieuwenhuizen: you know I've been thinking about doing it for the WM that I was using but also the new tasks a compositor has to do (things like input, screensharing etc.) also makes me scared of maintaining it long term
18:52ccr: bnieuwenhuizen, which is why I said what I said above. the big problem I saw when Wayland was a new thing was with Weston being "monolithic"
18:52emersion: bnieuwenhuizen: what's your WM then? :P
18:52karolherbst: bnieuwenhuizen: sure, but compositors are important
18:52ccr: should've focused earlier on making things modular
18:53karolherbst: and if you are not dedicated, then don't do it
18:53karolherbst: but that didn't really change with wayland. And wlroots is this idea of at least sharing the common stuff
18:53emersion: bnieuwenhuizen: (with wlroots screensharing is 2 lines of code, and the rest is shared infrastructure)
18:54bnieuwenhuizen: emersion: xmonad (not caring about the Haskell part at all, tried switching to sway and then found I had some minor inconveniences with different dpi & xwayland + some games not working... and the actual usage seemed more complicated than xmonad but that may be just getting used to it)
18:54emersion: there is https://github.com/waymonad/waymonad that needs help
18:54soreau: emersion: so teamviewer works now? :)
18:54karolherbst: please uninstall teamviewer
18:54karolherbst: it's a rootkit
18:55ccr: to be honest I still kinda think wayland is "10 years off in the future", but I'm old and grumpy and not interested in trying new things just for shits'n'giggles
18:55emersion: i mean, it's fine for users to keep using X11
18:55karolherbst: well, wayland isn't broken as X regarding security
18:55bnieuwenhuizen: emersion: I actually don't know Haskell to a practical extent and learning a new language for something I want to be low effort may not be the right decision there :P
18:55karolherbst: emersion: no
18:56karolherbst: it really isn't
18:56emersion: i mean, i won't stop them
18:56karolherbst: I consider all machines running X untrusted
18:56karolherbst: but they really shouldn't
18:56emersion: bnieuwenhuizen: i see
18:56karolherbst: applications can just record what you are typing and recording your screen and you won't get told if they do?
18:57bnieuwenhuizen: I think the implications are also interesting downstream, like if we don't release new modifier support and people keep using X, and what point can we mandate modifiers in the ecosystem?
18:57karolherbst: withw ayland
19:00exit70[m]: in arm, it appears to me that few systems are shipping images with wayland?
19:01bnieuwenhuizen: btw, now that we're talking X+wayland, is there a good way to detect Xwayland from an X11 connection (say from mesa WSI)?
19:01karolherbst: bnieuwenhuizen: why would you want to do that?
19:01karolherbst: but yeah, you can check the connector name
19:02bnieuwenhuizen: karolherbst: disallow non-vsynced WSI
19:02karolherbst: uhm.. screen name
19:02karolherbst: bnieuwenhuizen: ahh
19:02karolherbst: maybe there is a better way
19:02karolherbst: but that's what I know should work
19:14airlied: made /. now
19:34tango_: karolherbst: honestly I've found the “it's better because it's more secure” thing about wayland rather perplexing
19:34karolherbst: tango_: I never said that
19:34tango_: karolherbst: OK 8-)
19:34karolherbst: I just said, that Xorg is so insecure, users shouldn't use it :p
19:34karolherbst: although I guess it would be fine if you don't run any propriatary code and don't use the internet
19:35karolherbst: but people also install teamviewer.. so maybe I am too optimistic here
19:36tango_: karolherbst: it's not just that they install it, it's that they expect it to work, and sometimes even need it for work
19:36tango_: which is moronic, but hey what're you gonna do
19:36tango_: I'm more miffed about the lack of support for xdotool
19:37tango_: the thing is, X might have been broken security-wise, but the brokenness at least allowed a lot of fancy and useful things too
19:37karolherbst: well on my system I can't use X :p
19:37tango_: wayland goes to the other extreme without actually being designed with security in mind (e.g. no security context attached to each connection)
19:38karolherbst: xdotool shouldn't exit btw
19:38karolherbst: this entire xtest stuff was just missused for those shengians
19:38tango_: I disagree
19:38karolherbst: no I mean from a perspective how xtest was supposed to use
19:38tango_: it has been quite useful to me to work around some massive brokenness in certain cases
19:38karolherbst: xtest was never intented to be used for tools like xdotool
19:39karolherbst: not saying the feature is wrong, just that applications never cared about security
19:39karolherbst: and just used some API doing the trick
19:39karolherbst: but X has a lot of those horribly broken APIs nobody wants to disable
19:39karolherbst: so that's why we need wayland
19:39karolherbst: we could also remove xtest and add alternative APIs not granting random applications to do everything
19:39karolherbst: but... well
19:40karolherbst: then we have the same discussion "xtest allowed me to do this just like that, now I have to agree"
19:40tango_: honestly I don't think wayland is the correct way to do things either
19:40karolherbst: do it better then :p
19:40tango_: karolherbst: too busy doing other stuff
19:40tango_: I'll just wait for arcan ;-)
19:41karolherbst: yeah, arcan is another mistake
19:42tango_: how is it a mistake? it's a guy scratching its own itch
19:42karolherbst: it uses lua
19:43tango_: I mean, if that's the worst one can say about it, it's already way ahead of anything else ;-)
19:43karolherbst: also, it trust applications too much
19:43karolherbst: its security model sucks
19:44tango_: it's still better than wayland
19:44tango_: at least it has security context info at the protocol level
19:44karolherbst: why would that be a good thing?
19:45letoram: karolherbst: do elaborate ..
19:45karolherbst: I don't want applications to define what is allowed or what not
19:46letoram: because if the wm has access to the security model it can at least indicate that if you are sending sensitive data from a privileged context to an untrusted context that's a bad thing, or block it outright
19:46tango_: karolherbst: my understanding is that the applications define what they want, the wm decides if they're allowed or not
19:46letoram: since I wrote a ph.d thesis on the security model, I'm quite sure that it 'doesnt trust applications'
19:47karolherbst: the thing is, can an application prevent text being copied from it?
19:48letoram: yes .. the wm has to explicitly enable all routing between clients
19:48karolherbst: it kind of sounds like an application can decline any interaction, just wondering if that's true or I misread
19:48karolherbst: I don't mean the wm, I meant an application
19:50tango_: karolherbst: counterpoint: what if I the user want to copy the text?
19:51tango_: shouldn't I have control over what my machine and applications do?
19:51karolherbst: then it should be allowed
19:51tango_: karolherbst: so the control should be decided by the wm (= via user control), not the app
19:51karolherbst: yeah, it just sounded like in arcan the applications can prevent certain things
19:51karolherbst: maybe I missread
19:52letoram: karolherbst: on the contrary, the applications are even being abused in a sense ..
19:52letoram: part of the funding is tools for modelling deception
19:52tango_: karolherbst: an application can always prevent text from being copied by only provided bitmap images though, regardless of display server
19:52letoram: i.e. through virtualising something, like say the browser, building automated tools for poisioning adtech collection ..
19:53letoram: see the article on the blog for leveraging the display server privilege for 'improving debugging'
19:55letoram: tango_: only providing pixmaps just reduces the problem to computer vision, those tools aren't hard today
19:56tango_: letoram: of course
20:07karolherbst: letoram: there are a few things I am wondering about after reading a bit more about internals: what happens if a GPU disappears?
20:08karolherbst: or if you have a multi GPU setup and need to transition a client to a different device
20:08karolherbst: how does arcon allow this stuff
20:08letoram: karolherbst: back to directX4.0 days ..
20:08letoram: vram is volatile - client is expected to be able to rebuild its on-gpu state
20:09karolherbst: sure, but I meant the windowserver as well
20:09letoram: the window-manager has a separate privileged api, there's target_devicehint(pid, devid) that will give the client an event with the render-node to the new gpu
20:10imirkin: are there any gnustep-style wayland compositors?
20:10imirkin: (probably the wrong channel for such a question, but i figure someone here will know)
20:10karolherbst: letoram: uhm, right, but I was more wondering what if the window manager has to switch as well and how does it affect all clients
20:10karolherbst: or well..
20:10karolherbst: how does it deal if it has to display on several GPUs with per GPU contexts etc...
20:11karolherbst: as let's face it, prime for displaying the desktop is a mistake
20:11letoram: karolherbst: 90% of that is done (under the article 'chasing moby blit') test case is hotplug gpu compositing on eglstreams/gbm and one is lost
20:12letoram: but the engine works fine rebuilding everything on a new gpu (some caveats with shader capabilities but that's why crash recovery is a necessity)
20:13letoram: the quirky cases is gpu-affinity tracking, does (texture) belong to gpu-1, gpu-2 or both?
20:13karolherbst: mhh, I meant it in a different way though
20:13karolherbst: so let's say you have two GPUs and you have displays attached to both of them
20:13karolherbst: so you want to composite on each GPU
20:14karolherbst: and applications are having their context on one of them
20:14karolherbst: and the window manager is compositing either on the same or the different GPU, depending on where the windows of the applications are displayed
20:15karolherbst: but if now one GPU gets reaped, the window manager needs to 1. tear down the context from the one GPU 2. move each client from the reaped GPU over to one of the remaining ones
20:17karolherbst: so at this point I am wondering how much of a client depends on what the window manager has its resources
20:17karolherbst: and where do clients draw their contents into
20:18letoram: there is a bit to unpack here, but design wise (this doesn't translate well to specialised clients like the wayland implementation)
20:18letoram: clients by default get software only, one allocation (that is to have a path to communicate that hey, fix your perimissions)
20:19letoram: if that context is extended to accelerated, it receives render-node etc. from the display server, routed synch through the wm
20:20letoram: this can be revoked in two stages - one is the gpu failed outright (KHR_shoot_me_now) and handle passing fails - fallback to readback + copy transfer
20:20letoram: the second is receiving a new render-node to rebuild on
20:22letoram: it is also frequently tested through the network layer (there is such a thing) -
20:22letoram: 'hey the accelerated GPU died... and the display server... here's a new connection point (proxy) rebuild there!)
20:23letoram: https://www.youtube.com/watch?v=_RSvk7mmiSE <- that's what's happening there
20:24karolherbst: letoram: what about overlapping windows?
20:25karolherbst: or well.. you might want to have your client render to the power efficient GPU, not the one used for rendering the part of the desktop you have the client displayed on
20:25karolherbst: which you know, happens once a client is displayed on two displays
20:26karolherbst: from a different GPU each
20:27karolherbst: also you probably don't want to migrate the client just because the user moved the window over
20:28karolherbst: which also has fun corner cases once the displays even have different DPIs
20:28karolherbst: so like what happens if a windows get dragged from a FHD to a 4K one
20:28karolherbst: and it's displayed correctly on both even while dragging
20:29letoram: that's a separate case that takes more WM juggling -
20:29letoram: mixed-DPI rendering is a 3rd class citizen as it will just get shittier with HDR etc. you won't win - not different from when the printer server was around
20:29karolherbst: well you also want to notify clients that they should redraw with a different DPI setting
20:30letoram: DISPLAYHINT events carries ' I want you to render with this DPI (/channel orientation) as your native '
20:30karolherbst: letoram: but why wouldn't that work?
20:30letoram: it does work, but there is a few caveats ..
20:31letoram: but GPU and output-density are two very different things
20:31danvet_: bnieuwenhuizen, implicit set/get_tiling is dead on i915 discrete
20:31danvet_: not sure how much that will matter
20:32karolherbst: letoram: sure, those are just features I expect from modern desktops to just work
20:32bnieuwenhuizen: danvet_: I think the thing is that for AMD we still use xf86-video-amdgpu which doesn't support modifiers
20:32bnieuwenhuizen: making implicit modifiers dead is a hard sell for a HW manufacturer if we still have significant users
20:32karolherbst: none of the wayland compositors do the per GPU compositing yet
20:32karolherbst: but that's something we will require
20:33karolherbst: client migrations? oh well, that maybe as well
20:33karolherbst: but how to tell clients to migrate anyway or should that be magic?
20:33danvet_: bnieuwenhuizen, upstream probably could
20:33danvet_: not sure it's worth it
20:33karolherbst: and how do you know that clients can handle it
20:33karolherbst: what if they open drm devices themselves
20:33karolherbst: and with OpenGL/Vulkan they do
20:33danvet_: emersion, I'd filter the xserver repo first before you cut a release for xwayland
20:34bnieuwenhuizen: danvet_: the other thing was I thought modifiers require atomic?
20:34danvet_: and have a script to cherry-pick over automatically
20:34danvet_: bnieuwenhuizen, no
20:34danvet_: well -modesetting is sufficiently silly that it needs atomic to enable modifiers
20:34danvet_: but modifiers only needs modifiers
20:34bnieuwenhuizen: danvet_: if that is the case maybe it is worth backfilling modifier support in xf86-video-amdgpu
20:34bnieuwenhuizen: (I was thinking it needed atomic in which case I'd rather migrate evryone to -modesetting)
20:34danvet_: except if you have to deal with lolz like i915 gpus where you need atomic to handle the dynamic constraints
20:35danvet_: but for something like -amdgpu or when you just allow users to enable it, it should be fine
20:35bnieuwenhuizen: but with -modesetting not receiving any releases either it is hard to get feature parity ...
20:35danvet_: (there's I think more than just i915 being funny this way, but I think -amdgpu isn't)
20:35danvet_: bnieuwenhuizen, the problem is, the -modesetting atomic isn't even close
20:36danvet_: daniels said half to one year full time effort to essentially reimplement what he's done in weston
20:36bnieuwenhuizen: well at least atomic being hard was my argument for not redoing it in -amdgpu :P
20:36letoram: karolherbst: the wm has an api call for migration, both a 'go away, now' and a 'in case you dont hear from me, go here' (target_displayhint(pid, "my_second_desktop") or target_displayhint(pid, "a12:host@..")
20:36danvet_: but if you just want to retire the implicit ioctl for amdgpu going forward
20:36danvet_: backporting addfb2 with modifiers should be fairly ok-ish
20:36danvet_: the code is all there from -modesetting
20:37danvet_: the trouble is when your modifiers allow fancy new modes with special constraints and you need TEST_ONLY atomic
20:38daniels: just tabbed over because of the highlight, and I'm impressed that we've managed to replicate the giant comment thread over here too
20:38letoram: karolherbst: the other bit is used for accessibility (and relates to the debugging article), the display server can request multiple views of the same contents (or at an logic offset) at different offsets or color space)
20:38bnieuwenhuizen: danvet_: apologies!
20:38letoram: bah that expanded wrong - ... anyhow, WM can push a new window onto the client with the semantics, I want you to draw <insert type> here..
20:39daniels: less glibly per se, the X.Org internal ABI is (imo) incredibly difficult to change, and (factually) the basis for the original KMS ABI
20:39daniels: so walking back from there to atomic requires unpicking a lot of server internals as well as driver API
20:39daniels: it's doable, but it needs someone who knows the internals well to sit down and spend some time doing it
20:40daniels: karolherbst: 'per-GPU compositing' - that's super difficult because you fall into the 1990s X11 trap of not being able to drag windows between different screens
20:40karolherbst: daniels: and still we require it
20:40daniels: or, you can do it, but in order to present something you need to rely on the client being responsive and able to submit another frame on demand
20:40letoram: so in the 'display a is hdpi, hdr' 'display b is classic..', the client gets a window explicitly pushed with instructions that the WM/server wants both views
20:41letoram: if the client maps the new window - the server knows this and that the client can handle it
20:41karolherbst: daniels: well, depends on how that gets implemented
20:41daniels: both Mutter/Wayland and X.Org/modesetting are at the current state of the art - pick one GPU as your arbitrary primary, stick with it forever, do copies from that GPU to the 'secondary' if required
20:41bnieuwenhuizen: daniels: or transfer the frame over?
20:41karolherbst: daniels: sure, but GPUs can go away
20:42letoram: if it doesn't, well, pick a type-apropriate content-aware upsampler, composite one slice with one set of properties and another with the other
20:42daniels: karolherbst: right, but I don't understand what your suggestion is
20:42karolherbst: and also, if your iGPU is FHD and your eGPU has 2x 4K screens prime is not viable
20:42karolherbst: or well.. I guess you can use up all your PCIe bandwidth
20:42letoram: try having eInk as the second screen..
20:42karolherbst: but then the next user has 3x 5K or 8K screens
20:43karolherbst: and you slowly notice that your PCIe bus is slow
20:43karolherbst: because TB3 and only 4 lanes
20:43daniels: bnieuwenhuizen: yep. that's probably the primary cultural disconnect, in that X11 fixes all of its design flaws with just more and more and more copies. we got scarred very hard by that, because on non-AMD/NV platforms you don't actually have infinite memory bandwidth, and as a result we have a pathologically-ingrained avoidance of copies :P
20:43daniels: bnieuwenhuizen: but that's basically the state of the art atm
20:43karolherbst: I don't see how we get around per GPU compositing
20:43karolherbst: and client GPU migrations
20:43daniels: karolherbst: yep, just as long as it's reasonably dynamic
20:44bnieuwenhuizen: daniels: ah I was more thinking about one time copies when you migrate from compositing on one GPU to compositing on the next (i.e. not in stable state)
20:44karolherbst: you need to be able to move clients around as you like
20:44bnieuwenhuizen: though the price is obviously more complexity in a migration mechanism :)
20:44daniels: that's something that's WIP; it was started and unfortunately never properly finished, but I was literally discussing about an hour ago about hopefully picking that up for the end of this year ...
20:44karolherbst: and the compositor should be able to handle a removed GPU and everything
20:44karolherbst: and clients as well.. well, some
20:44karolherbst: don't care if games die
20:44airlied: i hzd an x server that cluld kigrate x apps between gpus
20:44airlied: could migrate
20:45daniels: bnieuwenhuizen: right, our philosophy has always been to start from absolutely zero copies required whatsoever, suck up the pain associated with that, and then compromise on something which can involve copies, but only in a transition, not steady state
20:45airlied: it was a wonder of engineering
20:45karolherbst: but I think we also need this context menu -> migrate to X GPU option
20:45karolherbst: or do it automatically?
20:45karolherbst: but how do we know clients support it?
20:45daniels: bnieuwenhuizen: (my feeling is that if you do anything short of that, then people will come to rely on the copies and use them to paper over all the cracks - but maybe that's just PTSD)
20:45daniels: airlied: was it ever released?
20:46airlied: a branch in my repo?
20:46bnieuwenhuizen: daniels: well that is the challenge of product management, saying yes just enough times but not more than that :P
20:46daniels: airlied: ahh, the Xnomad release mechanism
20:46daniels: bnieuwenhuizen: :)
20:46airlied: it was the basis for what we ended up with in gou screens
20:47airlied: it just took it a step further and separated protocol screen from driver screen
20:47daniels: karolherbst: well games dying is definitely not good - what's far worse is that you hotplug a display and then Blender/NukeX crashes and you lose a couple of hours of work
20:47karolherbst: daniels: well, if your games starts on the eGPU and you disconnect it, what do you do?
20:47airlied: then gou migration was instantiate new driver screen, migrate all apps, kill old driver screen
20:47daniels: karolherbst: cry
20:48karolherbst: also the user knows :p
20:48karolherbst: it's the windows behaviour
20:48airlied: but wayland was coming so i gave up on caring
20:48karolherbst: but at least applications doing gtk3/qt5 should get migrated
20:48karolherbst: and toolkits should ust support it
20:48airlied: and mutter will surely fix all of this in 10 years time
20:48letoram: karolherbst: that's what I meant with directX4 btw. at that time if you alt-tabbed out of fullscreen it was a loss of a GPU practically speaking
20:48karolherbst: and then we are only 20 years behind
20:49daniels: well yeah, which is why I've not been at all against taking some temporary pain as well as the steady state is purely optimal - if you're sitting down watching a video or playing a game, then you want it to be perfect. if you're plugging displays in and out and dragging windows between them, you're not going to notice temporarily suboptimal behaviour, because you're doing destructive things to your environment
20:49karolherbst: letoram: right, but even OpenGL has a mechanism for that
20:49karolherbst: just most applications don't care
20:49karolherbst: or don't handle it
20:49karolherbst: daniels: sure, that's the same case with per DPI scaling anyway
20:49daniels: robustness == 'the abort callstack resolves to the app, not my driver'
20:49karolherbst: as long as it's not complelely dragged over, the rescaling won't happen
20:49letoram: it's in the 'resilience' category of features - if you don't, at all times, enforce/test it, some/many/most will cheap out of it by not doing anything
20:50karolherbst: at least in kwin that's the case
20:50karolherbst: and with rescaling I mean rescaling, _not_ resizing
20:50letoram: for the last 5 or so years I've had a process randomly kill my display server process..
20:50daniels: karolherbst: it's up to the compositor to decide what the primary is - Mutter decides based on the CRTC with the largest coverage
20:50karolherbst: daniels: so, the eGPU for users with eGPUs :p
20:50letoram: the first two years I lost.. some data, now I don't even care
20:50letoram: the clients just come back
20:51daniels: karolherbst: I don't mean coverage of global co-ord space, I mean the CRTC where the window has the greatest number of logical pixels
20:51karolherbst: ahh, sure
20:51daniels: so if 60% of your window is on output A and 40% is on output B, regardless of relative scale, Mutter will tell it to optimise for output A
20:51karolherbst: but it still does this "resizing" thing, no?
20:52daniels: specifically that's what it tells it to set its scale factor for
20:52karolherbst: but I utterly disliked mutter behaviour as the window will be wrong on one screen
20:54karolherbst: but yeah..
20:55daniels: well, there is no right answer there, it's just the least-bad thing
20:55karolherbst: how kwin handles it is kind of neat as you don't see it happening
20:55letoram: karolherbst: https://youtu.be/nqi7KlTl6Uc?t=30 - there you have the 'gpu to no gpu to gpu again' case
20:55daniels: which happens to be 17 different mutually-exclusive behaviours depending on your personal preference
20:55karolherbst: no, there is just one valid one and every other solution is stupid :p
20:55airlied: the only defensible one is copy OSX :=p
20:56bnieuwenhuizen: what does osx do?
20:56karolherbst: bnieuwenhuizen: like kwin behaves
20:56bnieuwenhuizen: what does kwin do?
20:56karolherbst: window have their proper size of each screen
20:56karolherbst: get rescaled at some point
20:56karolherbst: but they don't resize
20:56daniels: tbf this does actually work for everything but Xwayland
20:57karolherbst: xwayland keeps the DPI
20:57daniels: I can drag windows between mixed-DPI outputs on Mutter, and they retain equivalent logical size
20:57karolherbst: ahhh, so only xwayland clients resize?
20:57karolherbst: uhm.. X clients
20:57letoram: is it now that we suggest bringing back the font server from the printer being the first true hdpi display? ...
20:58letoram: (not entirely mocking it as it is better than arbitrary scale factors if you talk to DTP people..)
20:58karolherbst: but yeah, even X clients retain their size here with kwin, they just don't get updated DPI scaling information
20:58daniels: karolherbst: last I saw I believe that was true, yes
20:58karolherbst: and I think that's fine as hidpi is just horribly broken with X
20:59daniels: ('that' -> only Xwl clients have a jarring cross-output break in scale)
20:59karolherbst: just kwins upscaling is ... wrong
20:59karolherbst: too blurry
21:00karolherbst: I really don't see how upscaling a FHD client to 4K should be blurry at all
21:00karolherbst: and this is probably one of the most common cases you could have an optimized path for
21:03karolherbst: but anyway
21:03karolherbst: would be cool to have this per GPU compsiting and client migration stuff at some point :D
21:03karolherbst: sadly I just don't have the time myself to work on that stuff
21:04karolherbst: letoram: but yeah.. I think having a crashing compositor is at the moment the most annoying thing as well with wayland
21:04karolherbst: it really shouldn't take down applications
21:04karolherbst: but I guess that's also something compositors have to implement themselves
21:07letoram: an easy litmus test is: while true; do weston-terminal& done; if that live-locks you, gg. real-world wins.
21:09karolherbst: yeah well... but also quite "unimportant". If applications can just execute stuff on your machine you have other things to worry about than a DOS against your display server :p
21:10karolherbst: need to solve it on a sandbox level anyway
21:11karolherbst: or well.. just SIGKILL the compositor
21:11letoram: 'sandbox' isn't a panacea, there is no problem finding escapes from chromium or android still - you need privsep but that needs to be solved every.. step.. of.. the.. way -- if a connect-draw spin does it, you are far from it ..
21:11letoram: to DoS wayland is easier, it's math and look at wl_region and how that is implemented in pixman
21:12karolherbst: sure, but you can also just send a SIGKILL
21:12airlied: karolherbst: yeah mutter poses challenges to per gpu contexts
21:12karolherbst: or you know, just kill the seat
21:13letoram: kill.2 is not a seccmp necessity, write.2 is
21:13airlied: rewriting mutter is definitely not a small challenge!
21:14karolherbst: letoram: execv
21:14karolherbst: and I bet a lot of applications would just get that allowed as well
21:15karolherbst: but if you rely on seccomp you are not doing enough for sandboxing anyway
21:34emersion: > but I was literally discussing about an hour ago about hopefully picking that up for the end of this year ...
21:42daniels: emersion: of course the author of the wlroots implementation would need to pick it up as well :P
21:42emersion: daniels: the author of the wlroots implementation would be very happy to do so :)
21:54pcercuei: Is there a way to force a specific resolution for the emulated framebuffer at bootup?
21:54pcercuei: I'm trying "video=320x240@60" boot param but it doesn't seem to do much
22:01LiquidAcid: pcercuei, you mean like this? https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes
22:01LiquidAcid: i think you need to specify the connector as well, just the mode alone won't work afaik
22:04pcercuei: thanks, maybe that's what I'm missing