[opensuse-factory] Replacement proposal for the current display-manager.service
Hi Everyone, The current methodology around starting the Display Manager is a script that is provided by the XDM package and a single systemd unit file. The script is doing all kind of stuff it seems, but one of them is reading a sysconfig file to see which DM should be started. Most of our Display Managers (SDDM, GDM, Lightdm, etc) already have proper systemd support and provide their own unit files, but we are removing those in order to keep the above mentioned methodology working. My proposal would be to drop the current method (including the script and special unit files from the xdm package) and to utilize the proper systemd support from the installed Display Manager itself. One way (the easiest one) would be that an user can only have a single Display Manager installed and the are mutually exclusive. The installation and removal of the unit files can then be done within the DM package itself. The downside would be that the user can not easily choose which DM to use. The other way (which would be more comparable to the current method) is that the Display Managers are providing the proper unit files, but the installation of them is done through YaST. Like now, through the sysconfig editor, you can select which Display Manager should be used and this would install the corresponding unit files. The changes requires in YaST would be that the user can only select from a list of Display Managers. Once a DM is selected, YaST should validate if the corresponding unit file is present. If the unit file is not present, YaST should offer to install the package. After this YaST should install and enable the corresponding unit file. This would then generate the correct display- manager.service which is required by systemd to start the display-manager. I would appreciate on-topic replies, feasibility of a proposal and which proposal would be preferred. Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 26 January 2015 11.43:56 Raymond Wooninck wrote:
Hi Everyone,
The current methodology around starting the Display Manager is a script that is provided by the XDM package and a single systemd unit file. The script is doing all kind of stuff it seems, but one of them is reading a sysconfig file to see which DM should be started.
Most of our Display Managers (SDDM, GDM, Lightdm, etc) already have proper systemd support and provide their own unit files, but we are removing those in order to keep the above mentioned methodology working.
My proposal would be to drop the current method (including the script and special unit files from the xdm package) and to utilize the proper systemd support from the installed Display Manager itself.
One way (the easiest one) would be that an user can only have a single Display Manager installed and the are mutually exclusive. The installation and removal of the unit files can then be done within the DM package itself. The downside would be that the user can not easily choose which DM to use.
The other way (which would be more comparable to the current method) is that the Display Managers are providing the proper unit files, but the installation of them is done through YaST. Like now, through the sysconfig editor, you can select which Display Manager should be used and this would install the corresponding unit files.
The changes requires in YaST would be that the user can only select from a list of Display Managers. Once a DM is selected, YaST should validate if the corresponding unit file is present. If the unit file is not present, YaST should offer to install the package. After this YaST should install and enable the corresponding unit file. This would then generate the correct display- manager.service which is required by systemd to start the display-manager.
I would appreciate on-topic replies, feasibility of a proposal and which proposal would be preferred.
Raymond
I'm in favor of keeping the DM selection (the final choice by the user) in Yast which seems more coherent with the global experience we try to offer. There's one point to check is remote desktop login are still supported. (VNC X2go etc methods) I believe that having 3-4 DM installed shouldn't be that hard, the service are "masked" until one is chosen. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 26 January 2015 11:53:33 Bruno Friedmann wrote:
I'm in favor of keeping the DM selection (the final choice by the user) in Yast which seems more coherent with the global experience we try to offer.
There's one point to check is remote desktop login are still supported. (VNC X2go etc methods)
Hi Bruno, Why would be this an issue ? Is this something that xdm is taking care off right now, or is KDM/GDM/etc supporting this ? If it is the latter, then there shouldn't be any issues. If it is the first one, then we should split this out from xdm into a separate package. Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 26 January 2015 13.33:07 Raymond Wooninck wrote:
On Monday 26 January 2015 11:53:33 Bruno Friedmann wrote:
I'm in favor of keeping the DM selection (the final choice by the user) in Yast which seems more coherent with the global experience we try to offer.
There's one point to check is remote desktop login are still supported. (VNC X2go etc methods)
Hi Bruno,
Why would be this an issue ? Is this something that xdm is taking care off right now, or is KDM/GDM/etc supporting this ? If it is the latter, then there shouldn't be any issues. If it is the first one, then we should split this out from xdm into a separate package.
Raymond
Technically I've no ideas (the second assumption being the most probable from what I've seen) It was just a warning to be include in the global refactoring, before the sky fall down on certain users :-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 26 janvier 2015 à 11:43 +0100, Raymond Wooninck a écrit :
Hi Everyone,
The current methodology around starting the Display Manager is a script that is provided by the XDM package and a single systemd unit file. The script is doing all kind of stuff it seems, but one of them is reading a sysconfig file to see which DM should be started.
Most of our Display Managers (SDDM, GDM, Lightdm, etc) already have proper systemd support and provide their own unit files, but we are removing those in order to keep the above mentioned methodology working.
My proposal would be to drop the current method (including the script and special unit files from the xdm package) and to utilize the proper systemd support from the installed Display Manager itself.
One way (the easiest one) would be that an user can only have a single Display Manager installed and the are mutually exclusive. The installation and removal of the unit files can then be done within the DM package itself. The downside would be that the user can not easily choose which DM to use.
The other way (which would be more comparable to the current method) is that the Display Managers are providing the proper unit files, but the installation of them is done through YaST. Like now, through the sysconfig editor, you can select which Display Manager should be used and this would install the corresponding unit files.
The changes requires in YaST would be that the user can only select from a list of Display Managers. Once a DM is selected, YaST should validate if the corresponding unit file is present. If the unit file is not present, YaST should offer to install the package. After this YaST should install and enable the corresponding unit file. This would then generate the correct display- manager.service which is required by systemd to start the display-manager.
I would tend to use first option: we already have something similar with the switch between network providers (wicked / NetworkManager) and Fedora is already using Aliases/symlink to switch between display managers. -- Frederic Crozat Project Manager Enterprise Desktop SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/26/2015 11:43 AM, Raymond Wooninck wrote:
Hi Everyone,
The current methodology around starting the Display Manager is a script that is provided by the XDM package and a single systemd unit file. The script is doing all kind of stuff it seems, but one of them is reading a sysconfig file to see which DM should be started.
Most of our Display Managers (SDDM, GDM, Lightdm, etc) already have proper systemd support and provide their own unit files, but we are removing those in order to keep the above mentioned methodology working.
My proposal would be to drop the current method (including the script and special unit files from the xdm package) and to utilize the proper systemd support from the installed Display Manager itself.
One way (the easiest one) would be that an user can only have a single Display Manager installed and the are mutually exclusive. The installation and removal of the unit files can then be done within the DM package itself. The downside would be that the user can not easily choose which DM to use.
The other way (which would be more comparable to the current method) is that the Display Managers are providing the proper unit files, but the installation of them is done through YaST. Like now, through the sysconfig editor, you can select which Display Manager should be used and this would install the corresponding unit files.
The changes requires in YaST would be that the user can only select from a list of Display Managers. Once a DM is selected, YaST should validate if the corresponding unit file is present. If the unit file is not present, YaST should offer to install the package. After this YaST should install and enable the corresponding unit file. This would then generate the correct display- manager.service which is required by systemd to start the display-manager.
Hi Raymond, leaving out YaST, what would be the default workflow for user who just installs a single desktop manager? How should the validation be done? Have will the mapping between the device manager and unit file work? What happens if I uninstall (just via plain rpm -e) the currently selected DM? I'm not saying that your proposal is wrong, no way. However, I definitely want to avoid having "if DM is foo, install package bar" in the YaST code and I'd like package operations via rpm or zypper produce expected results. Jiri
I would appreciate on-topic replies, feasibility of a proposal and which proposal would be preferred.
Raymond
-- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 26 January 2015 12:58:29 Jiri Srain wrote:
leaving out YaST, what would be the default workflow for user who just installs a single desktop manager?
I assume you are talking here about the second proposal. This would mean that we need to set a default display-manager at installation time. This would be the same as the current situation. If I now remove GDM and replace it with KDM, then I need to make changes in the sysconfig area to reflect this. But the LIVE-cd's would come with a default setup, so this would not change.
How should the validation be done? Have will the mapping between the device manager and unit file work?
What validation ? The unit files that are being delivered from upstream all set the alias display-manager.service. So this means that if I install the SDDM display-manager, the sddm.service unit file is placed in the systemd directories. When I call systemctl enable sddm.service, then this would create the display-manager.service pointing to the sddm.service.
What happens if I uninstall (just via plain rpm -e) the currently selected DM?
Then the start of the display-manager will fail. But this is exactly as what happens now.
I'm not saying that your proposal is wrong, no way. However, I definitely want to avoid having "if DM is foo, install package bar" in the YaST code and I'd like package operations via rpm or zypper produce expected results.
That was just an example. We could also have YaST detect the installed unit files to see which display-managers are available on the system. Which would be a big improvement, as that today I can set whatever command or whichever display-manager in the sysconfig and the script will try to start it (and of course if it is not there it will simply fail). If we want to be fool-proof and that we have predictable results when we install a display-manager package, then we should go for option 1. Again today I can install GDM, SDDM, KDM, lightdm all at the same time and still have a failing system as that in sysconfig I have blabla set as the default display-manager. Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/26/2015 01:20 PM, Raymond Wooninck wrote:
On Monday 26 January 2015 12:58:29 Jiri Srain wrote:
leaving out YaST, what would be the default workflow for user who just installs a single desktop manager?
I assume you are talking here about the second proposal. This would mean that we need to set a default display-manager at installation time. This would be the same as the current situation. If I now remove GDM and replace it with KDM, then I need to make changes in the sysconfig area to reflect this. But the LIVE-cd's would come with a default setup, so this would not change.
Yes, I talk about the 2nd proposal. I may be wrong, but I believe that there is some magic in the scipts which has some kind of fallback. And, honestly, I think that this is something that should keep working.
How should the validation be done? Have will the mapping between the device manager and unit file work?
What validation ? The unit files that are being delivered from upstream all set the alias display-manager.service. So this means that if I install the SDDM display-manager, the sddm.service unit file is placed in the systemd directories. When I call systemctl enable sddm.service, then this would create the display-manager.service pointing to the sddm.service.
My understanding was that you wanted to ship the service files separately to assure that only one of them is installed.
What happens if I uninstall (just via plain rpm -e) the currently selected DM?
Then the start of the display-manager will fail. But this is exactly as what happens now.
I'm not sure (and even if it is, IMO this is a bug), anyway, I will not argue here since I have not tried that. Regardless what the implementation is, I prefer the behavior of YaST's script: If the selected (be it via sysconfig or any other way) UI front-end is available, use it. Otherwise, try the others.
I'm not saying that your proposal is wrong, no way. However, I definitely want to avoid having "if DM is foo, install package bar" in the YaST code and I'd like package operations via rpm or zypper produce expected results.
That was just an example. We could also have YaST detect the installed unit files to see which display-managers are available on the system. Which would be a big improvement, as that today I can set whatever command or whichever display-manager in the sysconfig and the script will try to start it (and of course if it is not there it will simply fail).
If we want to be fool-proof and that we have predictable results when we install a display-manager package, then we should go for option 1. Again today I can install GDM, SDDM, KDM, lightdm all at the same time and still have a failing system as that in sysconfig I have blabla set as the default display-manager.
I'd strongly prefer to have a fool-proof solution. Even with your proposal, I can imagine behavior like: - when installing the first DM, just make it default - when uninstalling default DM, make another one default If you decide to put this logic into YaST, you will have to replicate it for building the live images and in any case where YaST is not involved - which should IMO be avoided. Jiri -- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 26 January 2015 13:35:07 Jiri Srain wrote:
What validation ? The unit files that are being delivered from upstream all set the alias display-manager.service. So this means that if I install the SDDM display-manager, the sddm.service unit file is placed in the systemd directories. When I call systemctl enable sddm.service, then this would create the display-manager.service pointing to the sddm.service.
My understanding was that you wanted to ship the service files separately to assure that only one of them is installed.
No, the service files are shipped inside the package of the DM itself (as intended by upstream). So the GDM package would contain the gdm.service file itself and the KDM package would contain the kdm.service file. If we opt for option 1, then the installation of the KDM package would have the systemd macro's inside the %post and %postun scripts to install and enable (resp. disable and remove) the service file. This would then create the display-manager.service which is required by systemd.
What happens if I uninstall (just via plain rpm -e) the currently selected DM?
Then the start of the display-manager will fail. But this is exactly as what happens now.
I'm not sure (and even if it is, IMO this is a bug), anyway, I will not argue here since I have not tried that.
I tried to read the script that display-manager.service is currently starting and I am not sure what will happen. But if the script does fallback on something, then this is xdm and nothing else. This would mean that when a display-manager is uninstalled, we could enable the xdm.service by default. This would leave the user always with a display- manager as that I assume that the xdm package already has plenty of requires to have the similar setup at this moment.
Regardless what the implementation is, I prefer the behavior of YaST's script: If the selected (be it via sysconfig or any other way) UI front-end is available, use it. Otherwise, try the others.
Since when is YaST doing this ? The current scipt used to start the display- manager is provided with the XDM package. YaST just uses the sysconfig editor to set a variable inside the /etc/sysconfig/displaymanager file. YaST does this without checking anything and even on a system that doesn't contain GDM or KDM, I am still able to set one of those as the default DM. And upon a reboot I get a big surprise as that XDM will start. So this is then actually a YaST bug !
I'd strongly prefer to have a fool-proof solution. Even with your proposal, I can imagine behavior like: - when installing the first DM, just make it default - when uninstalling default DM, make another one default
If you decide to put this logic into YaST, you will have to replicate it for building the live images and in any case where YaST is not involved - which should IMO be avoided.
Based on this feedback it seems that it would be better/easier to build the logic into the DM packages itself and to drop the functionality from YaST completely. If we would go for using update-alternatives (as proposed by Ludwig), then I could imagine something like the following logic: 1) xdm package is always installed and will provide an xdm.service. Through update-alternatives the xdm.service is installed as display-manager.service but with the lowest priority. 2) kdm, gdm, lightdm, sddm, etc packages will provide their unit files and will install their respective unit-files. Upon installation it will create an alternative with a higher priority than the xdm alternative. The question here would be which one has the highest priority ? What would happen if I install two DM's at the same time (which one would be the default) ? This could be resolved by making the mutual exclusive, but then we are loosing the option for the user to install multiple display-managers. Question would be however if most of our users have actually installed more than one display-manager. (xdm excluded). Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/26/2015 02:01 PM, Raymond Wooninck wrote:
On Monday 26 January 2015 13:35:07 Jiri Srain wrote:
What validation ? The unit files that are being delivered from upstream all set the alias display-manager.service. So this means that if I install the SDDM display-manager, the sddm.service unit file is placed in the systemd directories. When I call systemctl enable sddm.service, then this would create the display-manager.service pointing to the sddm.service.
My understanding was that you wanted to ship the service files separately to assure that only one of them is installed.
No, the service files are shipped inside the package of the DM itself (as intended by upstream). So the GDM package would contain the gdm.service file itself and the KDM package would contain the kdm.service file.
If we opt for option 1, then the installation of the KDM package would have the systemd macro's inside the %post and %postun scripts to install and enable (resp. disable and remove) the service file. This would then create the display-manager.service which is required by systemd.
What happens if I uninstall (just via plain rpm -e) the currently selected DM?
Then the start of the display-manager will fail. But this is exactly as what happens now.
I'm not sure (and even if it is, IMO this is a bug), anyway, I will not argue here since I have not tried that.
I tried to read the script that display-manager.service is currently starting and I am not sure what will happen. But if the script does fallback on something, then this is xdm and nothing else.
This makes most sense. Unlike with YaST (where the start-up script knows and hardcodes all back-ends), it is not the case here.
This would mean that when a display-manager is uninstalled, we could enable the xdm.service by default. This would leave the user always with a display- manager as that I assume that the xdm package already has plenty of requires to have the similar setup at this moment.
I think that this is reasonable behavior. I would prefer that if any DM remains installed, it will be used, though.
Regardless what the implementation is, I prefer the behavior of YaST's script: If the selected (be it via sysconfig or any other way) UI front-end is available, use it. Otherwise, try the others.
Since when is YaST doing this ? The current scipt used to start the display- manager is provided with the XDM package. YaST just uses the sysconfig editor to set a variable inside the /etc/sysconfig/displaymanager file. YaST does this without checking anything and even on a system that doesn't contain GDM or KDM, I am still able to set one of those as the default DM. And upon a reboot I get a big surprise as that XDM will start. So this is then actually a YaST bug !
I was talking about the /sbin/yast2 script - which starts YaST itself. If the built-in logic decides (possibly even based on sysconfig value) to run Qt but Qt is not available, it tries Gtk and NCurses.
I'd strongly prefer to have a fool-proof solution. Even with your proposal, I can imagine behavior like: - when installing the first DM, just make it default - when uninstalling default DM, make another one default
If you decide to put this logic into YaST, you will have to replicate it for building the live images and in any case where YaST is not involved - which should IMO be avoided.
Based on this feedback it seems that it would be better/easier to build the logic into the DM packages itself and to drop the functionality from YaST completely. If we would go for using update-alternatives (as proposed by Ludwig), then I could imagine something like the following logic:
1) xdm package is always installed and will provide an xdm.service. Through update-alternatives the xdm.service is installed as display-manager.service but with the lowest priority.
2) kdm, gdm, lightdm, sddm, etc packages will provide their unit files and will install their respective unit-files. Upon installation it will create an alternative with a higher priority than the xdm alternative. The question here would be which one has the highest priority ? What would happen if I install two DM's at the same time (which one would be the default) ? This could be resolved by making the mutual exclusive, but then we are loosing the option for the user to install multiple display-managers. Question would be however if most of our users have actually installed more than one display-manager. (xdm excluded).
I believe that in this case, you have two options: First wins or last wins. I still believe that there should be a script which sets the default DM to specified one (similarly to the one in sysconfig), then you can integrate this functionality into YaST. Jiri -- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 26 Jan 2015 14:01, Raymond Wooninck <tittiatcoke@...> wrote: [snip]
I tried to read the script that display-manager.service is currently starting and I am not sure what will happen. But if the script does fallback on something, then this is xdm and nothing else.
This would mean that when a display-manager is uninstalled, we could enable the xdm.service by default. This would leave the user always with a display- manager as that I assume that the xdm package already has plenty of requires to have the similar setup at this moment.
If we can accept e.g. "xdm.service" as hard fallback for an invalid / link-missing-target display-manager.service we could try to get fedora/rh and upstream systemd to implement that inside systemd, e.g. as a option inside "xdm.service": [code] IsFallbackFor=display-manager.service [/code] Such a option would open up the way to use such a Fallback also for other services (e.g. network). Only one in such a "Alias=" group is valid for the "IsFallbackFor=" line (hopefully the most basic, deepest in the stack). Just an Idea. - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Raymond Wooninck schrieb:
The current methodology around starting the Display Manager is a script that is provided by the XDM package and a single systemd unit file. The script is doing all kind of stuff it seems, but one of them is reading a sysconfig file to see which DM should be started. [...] My proposal would be to drop the current method (including the script and special unit files from the xdm package) and to utilize the proper systemd support from the installed Display Manager itself.
By all means, yes please.
One way (the easiest one) would be that an user can only have a single Display Manager installed and the are mutually exclusive. The installation and removal of the unit files can then be done within the DM package itself. The downside would be that the user can not easily choose which DM to use.
Would that still allow to have several desktop environments installed in parallel? I haven't checked but I could imagine that each DE (or components of it) requires a specific DM. If the DMs conflict the DEs themselves would therefore conflict.
The other way (which would be more comparable to the current method) is that the Display Managers are providing the proper unit files, but the installation of them is done through YaST. Like now, through the sysconfig editor, you can select which Display Manager should be used and this would install the corresponding unit files.
Or we manage a display-manager.service symlink via update-alternatives. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 26 January 2015 13:22:37 Ludwig Nussel wrote:
One way (the easiest one) would be that an user can only have a single Display Manager installed and the are mutually exclusive. The installation and removal of the unit files can then be done within the DM package itself. The downside would be that the user can not easily choose which DM to use.
Would that still allow to have several desktop environments installed in parallel? I haven't checked but I could imagine that each DE (or components of it) requires a specific DM. If the DMs conflict the DEs themselves would therefore conflict.
I believe that non of the desktop environments have hard requirements on the display-manager. I know for sure for KDE and this will not change in the future either as that it can use easily lightdm and sddm as replacements. All DM's can start any of the installed desktop environments. I believe the only one that has a little tighter integration is GDM and Gnome, but also here I don't believe that Gnome actually has a hard requirement on GDM, but I leave it up to Dominique to answer this one.
Or we manage a display-manager.service symlink via update-alternatives.
Hmm. This is uncharted territory for me. Does systemd really work with this ? And what would be the benefit ? Just to provide a simpler interface to the user to select the wanted DM ? Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Raymond Wooninck schrieb:
On Monday 26 January 2015 13:22:37 Ludwig Nussel wrote:
Or we manage a display-manager.service symlink via update-alternatives.
Hmm. This is uncharted territory for me. Does systemd really work with this ?
No idea. Someone has to try to find out if that's a viable solution :-)
And what would be the benefit ? Just to provide a simpler interface to the user to select the wanted DM ?
It makes an rcdisplay-manager possible, yes. It could also avoid having two display managers enabled at the same time. But then to achieve that the install section would somehow need to be externally attached to display-manager.service rather than xdm, kdm etc. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Ludwig Nussel wrote:
Or we manage a display-manager.service symlink via update-alternatives.
But if we have multiple DMs installed, what would their priorities be? IOW, which DM would have the highest priority? -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Luca Beltrame schrieb:
Ludwig Nussel wrote:
Or we manage a display-manager.service symlink via update-alternatives.
But if we have multiple DMs installed, what would their priorities be? IOW, which DM would have the highest priority?
I don't know update-alternatives well enough to tell but I hope it has some default behavior in case alternatives have the same priority. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Raymond Wooninck <tittiatcoke@gmail.com> [2015-01-26 11:44]:
The current methodology around starting the Display Manager is a script that is provided by the XDM package and a single systemd unit file. The script is doing all kind of stuff it seems, but one of them is reading a sysconfig file to see which DM should be started.
Most of our Display Managers (SDDM, GDM, Lightdm, etc) already have proper systemd support and provide their own unit files, but we are removing those in order to keep the above mentioned methodology working.
My proposal would be to drop the current method (including the script and special unit files from the xdm package) and to utilize the proper systemd support from the installed Display Manager itself.
One way (the easiest one) would be that an user can only have a single Display Manager installed and the are mutually exclusive. The installation and removal of the unit files can then be done within the DM package itself. The downside would be that the user can not easily choose which DM to use.
I think that would be the worst possible option, having conflicting packages is a hassle and should be avoided at all cost, it leads to problems when people install more than one DE, makes switching between DM a pain.
The other way (which would be more comparable to the current method) is that the Display Managers are providing the proper unit files, but the installation of them is done through YaST. Like now, through the sysconfig editor, you can select which Display Manager should be used and this would install the corresponding unit files.
The changes requires in YaST would be that the user can only select from a list of Display Managers. Once a DM is selected, YaST should validate if the corresponding unit file is present. If the unit file is not present, YaST should offer to install the package. After this YaST should install and enable the corresponding unit file. This would then generate the correct display- manager.service which is required by systemd to start the display-manager.
That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working. That's also the reason why update-alternatives is not a good option apart from the problems of priorities. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jan 26, 2015 at 4:42 PM, Guido Berhoerster <gber@opensuse.org> wrote:
That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working.
That's also the reason why update-alternatives is not a good option apart from the problems of priorities.
This sounds like generator based on /etc/sysconfig/displaymanager could be an answer. The only problem is, when package is removed one would need to run daenon-reload to recreate unit. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Andrei Borzenkov <arvidjaar@gmail.com> [2015-01-26 14:47]:
On Mon, Jan 26, 2015 at 4:42 PM, Guido Berhoerster <gber@opensuse.org> wrote:
That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working.
That's also the reason why update-alternatives is not a good option apart from the problems of priorities.
This sounds like generator based on /etc/sysconfig/displaymanager could be an answer. The only problem is, when package is removed one would need to run daenon-reload to recreate unit.
I suppose that could be handled by a %postun scriptlet common to all display manager packages? -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 26 janvier 2015 à 15:59 +0100, Guido Berhoerster a écrit :
* Andrei Borzenkov <arvidjaar@gmail.com> [2015-01-26 14:47]:
On Mon, Jan 26, 2015 at 4:42 PM, Guido Berhoerster <gber@opensuse.org> wrote:
That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working.
That's also the reason why update-alternatives is not a good option apart from the problems of priorities.
This sounds like generator based on /etc/sysconfig/displaymanager could be an answer. The only problem is, when package is removed one would need to run daenon-reload to recreate unit.
I suppose that could be handled by a %postun scriptlet common to all display manager packages?
It won't work as soon as people modify /etc/sysconfig/displaymanager and "forget" to run systemctl daemon-reload. Using a symlink as "THE" way to store the default DM is better IMHO (that's what we did for network, deprecating the relevant entry in /etc/sysconfig/network/config). -- Frederic Crozat Project Manager Enterprise Desktop SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Mon, 26 Jan 2015 16:07:37 +0100 Frederic Crozat <fcrozat@suse.com> пишет:
Le lundi 26 janvier 2015 à 15:59 +0100, Guido Berhoerster a écrit :
* Andrei Borzenkov <arvidjaar@gmail.com> [2015-01-26 14:47]:
On Mon, Jan 26, 2015 at 4:42 PM, Guido Berhoerster <gber@opensuse.org> wrote:
That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working.
That's also the reason why update-alternatives is not a good option apart from the problems of priorities.
This sounds like generator based on /etc/sysconfig/displaymanager could be an answer. The only problem is, when package is removed one would need to run daenon-reload to recreate unit.
I suppose that could be handled by a %postun scriptlet common to all display manager packages?
It won't work as soon as people modify /etc/sysconfig/displaymanager and "forget" to run systemctl daemon-reload.
Using a symlink as "THE" way to store the default DM is better IMHO (that's what we did for network, deprecating the relevant entry in /etc/sysconfig/network/config).
Using symlink with multiple (more than two) implementations means you need to control priorities and select which one to chose when current is removed. This sounds suspiciously like what update-alternatives does :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Andrei Borzenkov <arvidjaar@gmail.com> [2015-01-27 04:21]:
В Mon, 26 Jan 2015 16:07:37 +0100 Frederic Crozat <fcrozat@suse.com> пишет:
Le lundi 26 janvier 2015 à 15:59 +0100, Guido Berhoerster a écrit :
* Andrei Borzenkov <arvidjaar@gmail.com> [2015-01-26 14:47]:
On Mon, Jan 26, 2015 at 4:42 PM, Guido Berhoerster <gber@opensuse.org> wrote:
That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working.
That's also the reason why update-alternatives is not a good option apart from the problems of priorities.
This sounds like generator based on /etc/sysconfig/displaymanager could be an answer. The only problem is, when package is removed one would need to run daenon-reload to recreate unit.
I suppose that could be handled by a %postun scriptlet common to all display manager packages?
It won't work as soon as people modify /etc/sysconfig/displaymanager and "forget" to run systemctl daemon-reload.
Using a symlink as "THE" way to store the default DM is better IMHO (that's what we did for network, deprecating the relevant entry in /etc/sysconfig/network/config).
Using symlink with multiple (more than two) implementations means you need to control priorities and select which one to chose when current is removed. This sounds suspiciously like what update-alternatives does :)
I don't think it is much of an improvement configuring display manager behavior through /etc/sysconfig/displaymanager while having to select the actual display manager through some other mechanism like update-alternatives. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 27 January 2015 09:44:36 Guido Berhoerster wrote:
I don't think it is much of an improvement configuring display manager behavior through /etc/sysconfig/displaymanager while having to select the actual display manager through some other mechanism like update-alternatives.
The question is if those settings in /etc/sysconfig/displaymanager are still really affecting the how the display manager works. I know that GDM and KDM a lot of their settings are no longer controlled by YaST, but through their respective configuration managers. (e.g. Most of the KDM settings are now controlled by the KDE systemsettings) So this would be a good opportunity to really look how and where we want to configure our display managers and have a final cleanup of these settings. Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Raymond Wooninck <tittiatcoke@gmail.com> [2015-01-27 09:56]:
On Tuesday 27 January 2015 09:44:36 Guido Berhoerster wrote:
I don't think it is much of an improvement configuring display manager behavior through /etc/sysconfig/displaymanager while having to select the actual display manager through some other mechanism like update-alternatives.
The question is if those settings in /etc/sysconfig/displaymanager are still really affecting the how the display manager works. I know that GDM and KDM a lot of their settings are no longer controlled by YaST, but through their respective configuration managers. (e.g. Most of the KDM settings are now controlled by the KDE systemsettings)
So this would be a good opportunity to really look how and where we want to configure our display managers and have a final cleanup of these settings.
LightDM reads DISPLAYMANAGER_AUTOLOGIN, DISPLAYMANAGER_PASSWORD_LESS_LOGIN, DISPLAYMANAGER_REMOTE_ACCESS, DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN, DEFAULT_WM. GDM reads DISPLAYMANAGER_AUTOLOGIN, DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN, and DISPLAYMANAGER_AUTOLOGIN. LXDM reads DISPLAYMANAGER_AUTOLOGIN and DEFAULT_WM. With the rest I'm not familiar. Autologin, remote login and the default DE are somewhat important for YaST so it doesn't need to have DMs-specific knowledge and so that such basic configuration persists when switching DMs. Not all DMs provide a GUI configuration tool either. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 01/27/2015 10:21 AM, Guido Berhoerster wrote:
* Raymond Wooninck <tittiatcoke@gmail.com> [2015-01-27 09:56]:
On Tuesday 27 January 2015 09:44:36 Guido Berhoerster wrote:
I don't think it is much of an improvement configuring display manager behavior through /etc/sysconfig/displaymanager while having to select the actual display manager through some other mechanism like update-alternatives.
The question is if those settings in /etc/sysconfig/displaymanager are still really affecting the how the display manager works. I know that GDM and KDM a lot of their settings are no longer controlled by YaST, but through their respective configuration managers. (e.g. Most of the KDM settings are now controlled by the KDE systemsettings)
So this would be a good opportunity to really look how and where we want to configure our display managers and have a final cleanup of these settings.
LightDM reads DISPLAYMANAGER_AUTOLOGIN, DISPLAYMANAGER_PASSWORD_LESS_LOGIN, DISPLAYMANAGER_REMOTE_ACCESS, DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN, DEFAULT_WM. GDM reads DISPLAYMANAGER_AUTOLOGIN, DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN, and DISPLAYMANAGER_AUTOLOGIN. LXDM reads DISPLAYMANAGER_AUTOLOGIN and DEFAULT_WM. With the rest I'm not familiar.
The same information for KDM can be found in the comments of this bug report (credits to Wolfgang Bauer) https://bugzilla.suse.com/show_bug.cgi?id=907907 Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 27 janvier 2015 à 06:21 +0300, Andrei Borzenkov a écrit :
В Mon, 26 Jan 2015 16:07:37 +0100 Frederic Crozat <fcrozat@suse.com> пишет:
Le lundi 26 janvier 2015 à 15:59 +0100, Guido Berhoerster a écrit :
* Andrei Borzenkov <arvidjaar@gmail.com> [2015-01-26 14:47]:
On Mon, Jan 26, 2015 at 4:42 PM, Guido Berhoerster <gber@opensuse.org> wrote:
That seems the only sensible possibility, YaST should generate the unit file based on /etc/sysconfig/displaymanager which it already modifies based on the installer control file depending on the chosen DE in the installer. /etc/sysconfig/displaymanager provides a generic means to configure display managers beyond which display manager to start and that should keep working.
That's also the reason why update-alternatives is not a good option apart from the problems of priorities.
This sounds like generator based on /etc/sysconfig/displaymanager could be an answer. The only problem is, when package is removed one would need to run daenon-reload to recreate unit.
I suppose that could be handled by a %postun scriptlet common to all display manager packages?
It won't work as soon as people modify /etc/sysconfig/displaymanager and "forget" to run systemctl daemon-reload.
Using a symlink as "THE" way to store the default DM is better IMHO (that's what we did for network, deprecating the relevant entry in /etc/sysconfig/network/config).
Using symlink with multiple (more than two) implementations means you need to control priorities and select which one to chose when current is removed. This sounds suspiciously like what update-alternatives does :)
Indeed :) -- Frederic Crozat Project Manager Enterprise Desktop SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2015 05:43 AM, Raymond Wooninck wrote:
Hi Everyone,
The current methodology around starting the Display Manager is a script that is provided by the XDM package and a single systemd unit file. The script is doing all kind of stuff it seems, but one of them is reading a sysconfig file to see which DM should be started.
Most of our Display Managers (SDDM, GDM, Lightdm, etc) already have proper systemd support and provide their own unit files, but we are removing those in order to keep the above mentioned methodology working.
My proposal would be to drop the current method (including the script and special unit files from the xdm package) and to utilize the proper systemd support from the installed Display Manager itself.
One way (the easiest one) would be that an user can only have a single Display Manager installed and the are mutually exclusive. The installation and removal of the unit files can then be done within the DM package itself. The downside would be that the user can not easily choose which DM to use.
The other way (which would be more comparable to the current method) is that the Display Managers are providing the proper unit files, but the installation of them is done through YaST. Like now, through the sysconfig editor, you can select which Display Manager should be used and this would install the corresponding unit files.
The changes requires in YaST would be that the user can only select from a list of Display Managers. Once a DM is selected, YaST should validate if the corresponding unit file is present. If the unit file is not present, YaST should offer to install the package. After this YaST should install and enable the corresponding unit file. This would then generate the correct display- manager.service which is required by systemd to start the display-manager.
Wouldn't parameterization of the unit file be an option in this case? display-manager@.service This way all DMs can be installed in parallel. YaST can create a dynamic list and switching is as simple as systemctl disable display-manager@gdm.service systemctl enable display-manager@lightdm.service Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJUxkdKAAoJEE4FgL32d2UkMqUH/0xrFLFybFf2t/DWQ4fHmMhR KHzFY+asdSM+U3pFFx5u8asD8cLM9WhpQx85+dTAFvGZmmt8Na39FD1g6bRN079n MxZc1X+6qMIwcUmQdpdBFr2WU5FKHIp9QYfdiIo6kFrd6RHh+8YEdgOxtpZfgVgY ceOIDSIMUkkIsk5IpVQK7nnSpLdBujq9ZmGyUPbc4rumCwCN0q6025GSiGuiqlXK CIYgrbE/MkxgSz+6bE8TdN3WjSJ8HL17th5BpjUyF67DOo27Q5rPeJ9QERnKweUw HdzuT93GGGnaOYkuaSaSH5u/siQiddcHVSSkxcSiX7hCRonYGzt2fSJB3jy2RV8= =d87T -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Robert Schweikert wrote:
Wouldn't parameterization of the unit file be an option in this case? display-manager@.service
If that's technically possible in this case (it looks so to me, but I'm not an expert), +1 to that, it sounds quite sensible. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 26.01.2015 um 14:55 schrieb Robert Schweikert:
Wouldn't parameterization of the unit file be an option in this case? display-manager@.service
Would that mean, that tab-completion would no more work in bash to find out which possible values (that is DMs) are available? That would decrease discoverability To me, update-alternatives seems to be the nicer way as you can not easily use more than one DM at a time anyway. Or conflicting packages that have little more than the unit-files and %post scripts Ciao Bernhard M. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlTGoNQACgkQSTYLOx37oWRh4gCgz5dSahGvhPOK5ji3NiPw/fuf 7WsAnR72NkoL6+a6m28Fy7gI1rUZuFEc =xQHc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Mon, 26 Jan 2015 11:43:56 +0100, Raymond Wooninck wrote:
Hi Everyone,
The current methodology around starting the Display Manager is a script that is provided by the XDM package and a single systemd unit file. The script is doing all kind of stuff it seems, but one of them is reading a sysconfig file to see which DM should be started.
Most of our Display Managers (SDDM, GDM, Lightdm, etc) already have proper systemd support and provide their own unit files, but we are removing those in order to keep the above mentioned methodology working.
My proposal would be to drop the current method (including the script and special unit files from the xdm package) and to utilize the proper systemd support from the installed Display Manager itself.
One way (the easiest one) would be that an user can only have a single Display Manager installed and the are mutually exclusive. The installation and removal of the unit files can then be done within the DM package itself. The downside would be that the user can not easily choose which DM to use.
The other way (which would be more comparable to the current method) is that the Display Managers are providing the proper unit files, but the installation of them is done through YaST. Like now, through the sysconfig editor, you can select which Display Manager should be used and this would install the corresponding unit files.
The changes requires in YaST would be that the user can only select from a list of Display Managers. Once a DM is selected, YaST should validate if the corresponding unit file is present. If the unit file is not present, YaST should offer to install the package. After this YaST should install and enable the corresponding unit file. This would then generate the correct display- manager.service which is required by systemd to start the display-manager.
I would appreciate on-topic replies, feasibility of a proposal and which proposal would be preferred.
How would the failsafe mode be handled in these scenarios? IOW, with your proposal, will the all features be kept and compatible? Or some must be dropped? thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 27 January 2015 07:44:17 Takashi Iwai wrote:
How would the failsafe mode be handled in these scenarios?
Which failsafe mode are you referring too ? The one that falls back to xdm if the other display manager is not found/installed ?
IOW, with your proposal, will the all features be kept and compatible? Or some must be dropped?
I assume that not all features can be kept as that we will no longer work with scripts, etc. However depending of how the new situation would be implemented, certain features might no longer be necessary. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Tue, 27 Jan 2015 08:33:39 +0100, Raymond Wooninck wrote:
On Tuesday 27 January 2015 07:44:17 Takashi Iwai wrote:
How would the failsafe mode be handled in these scenarios?
Which failsafe mode are you referring too ? The one that falls back to xdm if the other display manager is not found/installed ?
There is also "x11failsafe" boot option handling. It's a really neat feature, essential when you're experimenting with the graphics stuff.
IOW, with your proposal, will the all features be kept and compatible? Or some must be dropped?
I assume that not all features can be kept as that we will no longer work with scripts, etc. However depending of how the new situation would be implemented, certain features might no longer be necessary.
Yeah, but we really need to make clear what will be dropped *intentionally*, and they have to be discussed and approved. I'd like to avoid a de ja vue like: "oops, XYZ doesn't work any longer because of our glorious purification; sorry that's already done, no way back". thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 27 janvier 2015 à 17:46 +0100, Takashi Iwai a écrit :
At Tue, 27 Jan 2015 08:33:39 +0100, Raymond Wooninck wrote:
On Tuesday 27 January 2015 07:44:17 Takashi Iwai wrote:
How would the failsafe mode be handled in these scenarios?
Which failsafe mode are you referring too ? The one that falls back to xdm if the other display manager is not found/installed ?
There is also "x11failsafe" boot option handling. It's a really neat feature, essential when you're experimenting with the graphics stuff.
I didn't check what "x11failsafe" does but systemd unit can be conditional to specific kernel commandline, so I think you could have a "failsafe" unit which would start when x11failsafe is specified and all other display-manager services would not start if it is present. -- Frederic Crozat Project Manager Enterprise Desktop SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Tue, 27 Jan 2015 18:10:03 +0100, Frederic Crozat wrote:
Le mardi 27 janvier 2015 à 17:46 +0100, Takashi Iwai a écrit :
At Tue, 27 Jan 2015 08:33:39 +0100, Raymond Wooninck wrote:
On Tuesday 27 January 2015 07:44:17 Takashi Iwai wrote:
How would the failsafe mode be handled in these scenarios?
Which failsafe mode are you referring too ? The one that falls back to xdm if the other display manager is not found/installed ?
There is also "x11failsafe" boot option handling. It's a really neat feature, essential when you're experimenting with the graphics stuff.
I didn't check what "x11failsafe" does but systemd unit can be conditional to specific kernel commandline, so I think you could have a "failsafe" unit which would start when x11failsafe is specified and all other display-manager services would not start if it is present.
That sounds promising. Stefan, what else features do we need to care? AFAIK, currently it provides: 1. the selection of display-manager exec 2. fallback when the selection fails 3. x11failsafe boot option 4. keytable load in /etc/X11/xdm/keytable (should be conditionally?) 5. /var/run/*.pid management (optional) 6. /dev/xconsole permission management (optional) 7. start/stop/restart with change of DM selection 8. common shell functions that can be invoked by each script I guess 4, 5, 6 and 8 can be moved into each DM service. 1, 2 (and probably 7) have been discussed in this thread by other people. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jan 27, 2015 at 07:54:52PM +0100, Takashi Iwai wrote:
At Tue, 27 Jan 2015 18:10:03 +0100, Frederic Crozat wrote:
Le mardi 27 janvier 2015 à 17:46 +0100, Takashi Iwai a écrit :
At Tue, 27 Jan 2015 08:33:39 +0100, Raymond Wooninck wrote:
On Tuesday 27 January 2015 07:44:17 Takashi Iwai wrote:
How would the failsafe mode be handled in these scenarios?
Which failsafe mode are you referring too ? The one that falls back to xdm if the other display manager is not found/installed ?
There is also "x11failsafe" boot option handling. It's a really neat feature, essential when you're experimenting with the graphics stuff.
I didn't check what "x11failsafe" does but systemd unit can be conditional to specific kernel commandline, so I think you could have a "failsafe" unit which would start when x11failsafe is specified and all other display-manager services would not start if it is present.
Hmm. This doesn't look like the meaning of "x11failsafe" is understood. :-( It's used to specify a failsafe X config file (also used during installation; so this configuration should work as it did at that time). Usually fbdev driver based.
That sounds promising.
Stefan, what else features do we need to care? AFAIK, currently it provides:
1. the selection of display-manager exec 2. fallback when the selection fails 3. x11failsafe boot option 4. keytable load in /etc/X11/xdm/keytable (should be conditionally?) 5. /var/run/*.pid management (optional) 6. /dev/xconsole permission management (optional) 7. start/stop/restart with change of DM selection 8. common shell functions that can be invoked by each script
I guess 4, 5, 6 and 8 can be moved into each DM service. 1, 2 (and probably 7) have been discussed in this thread by other people.
I don't see /usr/lib/X11/displaymanagers/<dm> mentioned here, where important functions are defined. Thanks, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE LINUX GmbH Tel: 0911-740 53 0 Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.de Germany --------------------------------------------------------------- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) --------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
At Tue, 3 Feb 2015 17:51:43 +0100, Stefan Dirsch wrote:
On Tue, Jan 27, 2015 at 07:54:52PM +0100, Takashi Iwai wrote:
At Tue, 27 Jan 2015 18:10:03 +0100, Frederic Crozat wrote:
Le mardi 27 janvier 2015 à 17:46 +0100, Takashi Iwai a écrit :
At Tue, 27 Jan 2015 08:33:39 +0100, Raymond Wooninck wrote:
On Tuesday 27 January 2015 07:44:17 Takashi Iwai wrote:
How would the failsafe mode be handled in these scenarios?
Which failsafe mode are you referring too ? The one that falls back to xdm if the other display manager is not found/installed ?
There is also "x11failsafe" boot option handling. It's a really neat feature, essential when you're experimenting with the graphics stuff.
I didn't check what "x11failsafe" does but systemd unit can be conditional to specific kernel commandline, so I think you could have a "failsafe" unit which would start when x11failsafe is specified and all other display-manager services would not start if it is present.
Hmm. This doesn't look like the meaning of "x11failsafe" is understood. :-(
It's used to specify a failsafe X config file (also used during installation; so this configuration should work as it did at that time). Usually fbdev driver based.
That sounds promising.
Stefan, what else features do we need to care? AFAIK, currently it provides:
1. the selection of display-manager exec 2. fallback when the selection fails 3. x11failsafe boot option 4. keytable load in /etc/X11/xdm/keytable (should be conditionally?) 5. /var/run/*.pid management (optional) 6. /dev/xconsole permission management (optional) 7. start/stop/restart with change of DM selection 8. common shell functions that can be invoked by each script
I guess 4, 5, 6 and 8 can be moved into each DM service. 1, 2 (and probably 7) have been discussed in this thread by other people.
I don't see /usr/lib/X11/displaymanagers/<dm> mentioned here, where important functions are defined.
I included it implicitly in 1 and 2. Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (14)
-
Ancor Gonzalez Sosa -
Andrei Borzenkov -
Bernhard M. Wiedemann -
Bruno Friedmann -
Frederic Crozat -
Guido Berhoerster -
Jiri Srain -
Luca Beltrame -
Ludwig Nussel -
Raymond Wooninck -
Robert Schweikert -
Stefan Dirsch -
Takashi Iwai -
Yamaban