Re: [DNG] [ASCII][PATCH] startx to a new tty
Steve Litt il 18-09-18 00:29:59 ha scritto: > Your idea merits more research. The "we must cover every corner case" > crowd can use startx in its Redhat-diminished state, while people like > us use a <20 line shellscript. Perhaps call it viverna. I call it "ax" (acronym for Avvia (italian word for starts) X). At first I wrote "ax" because I liked change WM/DE very often. I like lxde and openbox but I used gnome2 (in the past) and I use rarely kde and play with other WM/DE. Change .xinitrc is easy but not immediate and I developed several years ago a personal shell script. So when I want run lxde: ax lxde when I want run openbox: ax openbox... and so on. Almost a year ago I rewrite this shell script to be suitable for distribution, I will be happy if it may be useful for someone: https://notabug.org/viverna/ax Execute: ax [your_favorite_wmde] for example: ax lxde ax kde ax without parameters run last WM/DE or the default. ax understands WM/DE reading $ETCPREFIX/etc/ax/client (for me $ETCPREFIX is /usr/local). "client" file has a very simple syntax: NAME_WMDE NAME_EXECUTABLE MULTIPLE_ARGS_EXECUTABLE for example: https://notabug.org/viverna/ax/src/master/etc/client usage: https://notabug.org/viverna/ax/src/master/USAGE.txt xinit args are the output of args.sh file in $ETCPREFIX/etc/ax/ I use everyday and works well but it is my personal case and it needs more tests. -- viverna ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [ASCII][PATCH] startx to a new tty
On Mon, 17 Sep 2018 23:53:39 +0200 viverna wrote: > Steve Litt il 16-09-18 22:21:11 ha > scritto: > > Then here's a solution that bridges all the options: Release Dario's > > version of startx under some other name, so that Gnome/KDE people > > can still have their "features", and everyone else can have X that > > works and leaves the system in good shape when it terminates. Put > > it in the same package that startx comes in. Just use Dario's patch > > to make it, each time Debian changes startx. > Good solution. But I think Dario's solution should be the > default. > Another possibility is don't use startx and execute xinit from a > personal shell script and (fine grained) control all parameters > passed to xinit. This is my approach. If you are interested I write a > simple shell script and I will be happy if it may be useful for > someone. > The shellscript calling xinit was my first thought. Then I put startx in an editor. It does a WHOLE LOT of stuff I don't have the knowledge to recreate. It's 200 lines of bash, for gosh sakes. So, trying to prove your xinit idea couldn't possibly work, I did the following: xinit -- :8 Of course nothing that simplistic would work. Oops, it came right up in Openbox, same as my normal startx initiated vt7. Dmenu worked, gnumeric worked, Chromium didn't because it started itself in vt7 instead of vt8, but you usually have only one X at a time. Your idea merits more research. The "we must cover every corner case" crowd can use startx in its Redhat-diminished state, while people like us use a <20 line shellscript. Perhaps call it viverna. SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [ASCII][PATCH] startx to a new tty
Steve Litt il 16-09-18 22:21:11 ha scritto: > Then here's a solution that bridges all the options: Release Dario's > version of startx under some other name, so that Gnome/KDE people can > still have their "features", and everyone else can have X that works > and leaves the system in good shape when it terminates. Put it in the > same package that startx comes in. Just use Dario's patch to make it, > each time Debian changes startx. Good solution. But I think Dario's solution should be the default. Another possibility is don't use startx and execute xinit from a personal shell script and (fine grained) control all parameters passed to xinit. This is my approach. If you are interested I write a simple shell script and I will be happy if it may be useful for someone. -- viverna ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [ASCII][PATCH] startx to a new tty
Hi Dario, On Sun, Sep 16, 2018 at 09:35:52PM +0200, Dario Niedermann wrote: > Il 16/09/2018 alle 18:43, Andreas Messer ha scritto: ddd> > I see. Anyway I strongly doubt that any DE relies on startx internally: > it's a shell script that's intended to provide a convenient user > interface to console users who want to spawn an X session. Yes a DE does not care how the X-server was started - by startx, by a display manager or something else. But startx can of course start a DE like KDE. And KDE depends on session management - at least some of its functionality. And for that to work properly, the session associated with KDE needs to be "active". > Also note that startx will *always* run X as root, even the stock Devuan > version. My patch doesn't change that. The 'needs_root_rights' variable As far as I understand this only happens when xserver-xorg-legacy package is installed. If this package is not installed, X will never run as root. > I add to 'Xwrapper.config' is only there for Xwrapper (a short lived > program called by startx) to be able to allocate a new tty. After which > it spawns X and quits. Manualpage of Xorg.wrap says something different. My understanding is, that for example using DRI - which actually means using a modern graphics card at all - either requires root permissions of the x server or a working session management. (Session management daemon will adjust permissions such that DRI is available to non-root) > With the stock RedHat-derived version, instead, a new tty is not > allocated: the current tty is taken over by X when you issue startx. > After X quits, the current tty is released, but is now owned by root > (no longer by your user). Which is not the way the XFree86 / Xorg > devs intended startx to work. I dont know much about that. My feeling about this is, that it is something which can not really be solved to fit all needs. From my point, there are two ways: Either have a working session management with running X without root permission or having no session management and running X as root. In the later case, X should have its own tty allocated indeed. So the decision if a new tty shall be allocated actually corellates to if X is running as root or not. Since only Xorg.wrap knows finally if it will run X with root permission or not, its the first place for me were modifications need to be made. Maybe the whole combination of startx/xinit/Xorg.wrap needs adjustments. Both affected packets (xinit, xserver-xorg-legacy) are currently taken unchanged from Debian. So if we were to modify them, forks of these packages have to be created in Devuan package git repos. There we can put the modifications for test and possible future integration. Decision on that is not mine. @Dario: If you want to see this changed, I'd like to encourage you to create an account on Devuan git and just start to work on this topic. cheers, Andreas signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [ASCII][PATCH] startx to a new tty
On Sun, 16 Sep 2018 18:43:12 +0200 Andreas Messer wrote: > Hi Dario, > > On Sun, Sep 16, 2018 at 10:59:52AM +0200, Dario Niedermann wrote: > > Il 16/09/2018 alle 10:01, Andreas Messer ha scritto: > > > > [...] > > In short: their addition was a kludge, 100% due to systemd: the only > > thing that was causing problems for them, with the X session being > > seen as "inactive", was systemd's logind component. > > Thanks for pointing that out. Unfortunately, many DEs have hopped on > the systemd train and therefore depend on its services. In particular, > the missing logind was the main barrier to have DEs like Gnome or KDE > fully working on Devuan. Last I heard we weren't even trying to get Gnome working on Devuan, because it was too ententicalated with systemd. > With fully working I refer to how standard > users would expected an desktop environment to behave. > > Therefor elogind was added to Devuan as a replacement for systemd's > logind. But actually elogind is just the logind component from > systemd mangled to run standalone. I expect it to show almost the > same behavior like the original one. > > > So, Devuan's stock startx is running code that's only there to > > accommodate systemd, and causes incorrect/non-traditional behaviour > > on a systemd-less OS. > > If we were to provide a modified version startx, we have to consider > constraints pointed out above. I'm not sure if /usr/bin/startx is > part of a packet currently manged/modified by Devuan at all. > (Most packets are original Debian ones, without any modification) Then here's a solution that bridges all the options: Release Dario's version of startx under some other name, so that Gnome/KDE people can still have their "features", and everyone else can have X that works and leaves the system in good shape when it terminates. Put it in the same package that startx comes in. Just use Dario's patch to make it, each time Debian changes startx. SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [ASCII][PATCH] startx to a new tty
Il 16/09/2018 alle 18:43, Andreas Messer ha scritto: > Thanks for pointing that out. Unfortunately, many DEs have hopped on > the systemd train and therefore depend on its services. In particular, > the missing logind was the main barrier to have DEs like Gnome or KDE > fully working on Devuan. With fully working I refer to how standard users > would expected an desktop environment to behave. > > Therefor elogind was added to Devuan as a replacement for systemd's > logind. But actually elogind is just the logind component from systemd > mangled to run standalone. I expect it to show almost the same > behavior like the original one. I see. Anyway I strongly doubt that any DE relies on startx internally: it's a shell script that's intended to provide a convenient user interface to console users who want to spawn an X session. Also note that startx will *always* run X as root, even the stock Devuan version. My patch doesn't change that. The 'needs_root_rights' variable I add to 'Xwrapper.config' is only there for Xwrapper (a short lived program called by startx) to be able to allocate a new tty. After which it spawns X and quits. With the stock RedHat-derived version, instead, a new tty is not allocated: the current tty is taken over by X when you issue startx. After X quits, the current tty is released, but is now owned by root (no longer by your user). Which is not the way the XFree86 / Xorg devs intended startx to work. Later, -- Dario Niedermann. Also on the Internet at: gopher://darioniedermann.it/ <> https://www.darioniedermann.it/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [ASCII][PATCH] startx to a new tty
Hi Dario, On Sun, Sep 16, 2018 at 10:59:52AM +0200, Dario Niedermann wrote: > Il 16/09/2018 alle 10:01, Andreas Messer ha scritto: > > [...] > In short: their addition was a kludge, 100% due to systemd: the only > thing that was causing problems for them, with the X session being seen > as "inactive", was systemd's logind component. Thanks for pointing that out. Unfortunately, many DEs have hopped on the systemd train and therefore depend on its services. In particular, the missing logind was the main barrier to have DEs like Gnome or KDE fully working on Devuan. With fully working I refer to how standard users would expected an desktop environment to behave. Therefor elogind was added to Devuan as a replacement for systemd's logind. But actually elogind is just the logind component from systemd mangled to run standalone. I expect it to show almost the same behavior like the original one. > So, Devuan's stock startx is running code that's only there to > accommodate systemd, and causes incorrect/non-traditional behaviour > on a systemd-less OS. If we were to provide a modified version startx, we have to consider constraints pointed out above. I'm not sure if /usr/bin/startx is part of a packet currently manged/modified by Devuan at all. (Most packets are original Debian ones, without any modification) cheers, Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [ASCII][PATCH] startx to a new tty
Il 16/09/2018 alle 10:01, Andreas Messer ha scritto: > Well, this is not really a Devuan Problem. It is more likely related > to session management present in most modern linux distros. [...] > As indicated with one of your links, this "keep-tty" stuff was introduced > to properly handle session management. Without the X-Session from "startx" > will considered "inactive" by session management and in turn several things > wont work as expected. E.g. udisks based mounting of Filessystems - This > covers for example Plug and Play use of USB-Sticks. Hi Andreas, if you follow the link in the patch* you can read the whole discussion that took place at RedHat, and led to their _adding_ the 5 lines to startx that my patch is deactivating. In short: their addition was a kludge, 100% due to systemd: the only thing that was causing problems for them, with the X session being seen as "inactive", was systemd's logind component. So, Devuan's stock startx is running code that's only there to accommodate systemd, and causes incorrect/non-traditional behaviour on a systemd-less OS. * https://bugzilla.redhat.com/show_bug.cgi?id=806491 -- Dario Niedermann. Also on the Internet at: gopher://darioniedermann.it/ <> https://www.darioniedermann.it/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
