On 2024-03-06 13:02, Mario Limonciello wrote: > On 3/6/2024 12:00, Xaver Hugl wrote: >> Am Mi., 6. März 2024 um 18:19 Uhr schrieb Mario Limonciello >> <mario.limonciello@xxxxxxx>: >>> So the idea being if the compositor isn't using it we let >>> power-profiles-daemon (or any other software) take control via sysfs and >>> if the compositor does want to control it then it then it writes a DRM >>> cap and we destroy the sysfs file? >> >> Yes. That way still only one party controls it at a given time, and we >> can get both good default behavior for display servers that don't care >> (like Xorg or compositors without color management support), and >> compositors that want to put in the effort can do more specific things >> with it. > > I think that's a very good solution. > > Harry, Hamza, what do you guys think? In theory I like it. But how will this look in practice? Is PPD or compositor on the scene first? Would it be possible to yank the sysfs away from PPD? DRM client caps are set by the client when the client interacts with DRM. At driver creation there is no client. How will the driver set things up? A user might switch between DRM clients (login manager, to desktop compositor, maybe to another VT with a different compositor). I know everything but the login manager to desktop compositor hand-off is today considered exotic, but what if someone starts building a use-case for it? I've done a bunch of gamescope or IGT work in a different VT while I've had Plasma running on its default VT. If someone can sketch this out, with answers to all the questions above and any other questions you can come up (be creative), I'd be happy to review. Alternatively we can discuss this at the hackfest and maybe arrive at a solution. Harry
