Re: Request for comment- tuned replacing power-profiles-daemon plan
On Thu, Oct 05, 2023 at 03:29:44PM +0800, Kate Hsuan wrote: > Hi Folks, > > We would like to replace power-profiles-daemon with tuned. There are > many power-related software that offer similar functions. Advanced > users may install several power management tools, for example, tuned > and power-profiles-daemon (ppd), and get confused about which tools > manage the system and cause unexpected behaviors for the system. By > integrating power-profiles-daemon with tuned, the user can get extra > features to finetune the system, and the basic feature provided by ppd > can be used according to the user's demand. It also can reduce the > efforts of the maintainer. > > The impact of this plan would be gnome-control-center (power panel), Also gnome-shell directly integrates with power-profiles-daemon. It is critical that both gnome-shell and gnome-control-center has no logic of their own to decide what a high level profile is, and changing the profile in gnome-control-center should immediately be reflected in gnome-shell, and vice versa. This is important because tweaking the profile with either gnome-control-center and gnome-shell should for all practical purposes do the exact same thing, meaning any actual logic must be a layer below them. This means something, e.g. tuned or a wrapper around it, needs to provide these high level profiles that power-profiles-daemon currently expose. > KDE, sysprof, and tuned (or some projects depending on ppd). We should > move the ppd API and features to tuned to provide the same features of > it. From the API aspect, we also can design a new API for the basic > feature, ppd provided but the software dependent on ppd should be > modified to use the new API. Although, for the long-term plan, a set > of new API is a good option. For the short-term plan, moving the > original one to tuned is good for those applications depending on ppd. Any long term future API must still provide the high level "dumb" API for gnome-shell and gnome-control-center to consume for the reasons described above. Jonas > > Moreover, the detailed change proposal can be found here. > https://fedoraproject.org/wiki/Changes/TunedReplacesPower-profiles-daemon > > If you have any suggestions, please let us know. > > Thank you. :) > -- > BR, > Kate > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)
On Tue, Jun 11, 2024 at 04:22:24PM +0200, Jiri Konecny wrote: > On 11. 06. 24 11:53, Neal Gompa wrote: > > On Tue, Jun 11, 2024 at 10:41 AM Jiri Konecny wrote: > > > On 04. 06. 24 14:27, Neal Gompa wrote: > > > > On Tue, Jun 4, 2024 at 8:23 AM Jiri Konecny wrote: > > > > > > > > > > On 03. 06. 24 21:57, Jason L Tibbitts III wrote: > > > > > > > > > > > Aoife Moloney writes: > > > > > > > === VNC switch to RDP for remote GUI installations === > > > > > > I'm curious how my usual install workflow will be affected by this > > > > > > change. I use the kickstart "vnc --connect" option extensively in > > > > > > my > > > > > > workflow; I may have a bunch of installs running in parallel, and > > > > > > they > > > > > > just connect and display when they are ready. I use vinagre as the > > > > > > vnc > > > > > > client. > > > > > > > > > > > > It's not a huge thing; I could come up with another workflow but > > > > > > that's > > > > > > the one I've used since before Fedora existed. The installs are > > > > > > fully > > > > > > automated and the display connection is only used so that I can see > > > > > > the > > > > > > progress and potentially interact with a machine if it encounters a > > > > > > problem. I guess in the worst case I could just do the install > > > > > > blind > > > > > > and ssh in if something takes too long. > > > > > Hi, the only change should be that you will change "vnc --connect" > > > > > with > > > > > the new API we will provide and also use RDP as your client instead > > > > > of VNC. > > > > > > > > > Given that gnome-remote-desktop supports both VNC and RDP, can't VNC > > > > support still be wired up? > > > > > > > Hi, it is theoretically possible but we are not planning to do that > > > until there will be a reason for that. AFAIK it's not that simple change > > > to do that. > > > > > I think the reason is pretty obvious: there are many more high quality > > VNC clients than there are RDP ones. And even ignoring that, the > > existing Anaconda workflows for remote GUI expect VNC. There is no > > technical limitation preventing us from having VNC support through > > grd. In fact, one of the original reasons I wrote the Weston backend > > for Anaconda was so that I could have VNC for Linux and web clients, > > because the RDP clients are not very good in my experience. > > > In any case, I would see this more like a future improvement if we agree to > go this way. I would like to simplify things for now, it's already a big > change. > > Anyway, Jonas, could you please share your recommendation here as owner of > grd? Do you think that VNC should be enabled in grd? Currently in upstream grd VNC support is implemented using LibVNCServer, and completely lacks any way of encryption. Other than that, there are awkward limitations of password lengths that may be present, depending on various factors. All in all, it's awful for security. There are three things that would make me comfortable recommending making VNC an option: * Changing implementation to use neatvnc instead of LibVNCServer. The impression I have is that this VNC implementation has a bit higher code quality compared to LibVNCServer. * Implement TLS key/cert based encryption and require that by default, while dropping the anontls support we have downstream in Fedora. * Remove the "prompt" authorization method from grd. Other than that, a probably unenforcable thing would be to not allow it being exposed to the wider Internet. Jonas > > Best Regards, > Jirka -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GNOME only: KeepassXC quirks
On Sat, May 01, 2021 at 10:49:57AM -0400, Owen Taylor wrote: > On Sat, May 1, 2021 at 10:09 AM Neal Gompa wrote: > > > > On Sat, May 1, 2021 at 9:48 AM Owen Taylor wrote: > > > > I agree, do we know anyone who understands Mutter that could work with > > someone who understands Qt to figure this out? I've got a couple of > > folks in mind who could help on the KDE side (who I've CC'd to this > > email). > > Added Jonas Adahl (all things output), Carlos Garnacho (all things > input) and Oliver Fourdan (compat problems expert) to the Cc:- one of > them should be able to help. > > Since the context is trimmed, the thread here is: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PZCV4KM5W2PI34GT2PK6QUGOVODVA6HW/ I have yet to find any recent bugs in mutter that causes issues that happens only with Qt; last time I and Jan debugged some issues with Dolphin and Kate resizing wierdly, there were still some Qt issues with incorrectly committed surface state. I think he is still looking into those. Some issues likely doesn't cause issues on kwin because kwin takes over window decoration from Qt applications, meaning Qts inability to commit correct state is papered over by the incorrect intermediate state not existing, but for example oddly placed menus (that I have seen and can reproduce) behave exactly the same in e.g. weston as in mutter. Jonas > > Owen > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
