Pmbootstrap: Display manager

Created on 30 Sep 2017  路  8Comments  路  Source: postmarketOS/pmbootstrap

Right now we configure the tty0 to automatically log in as user on boot (by editing the inittab in the postmarketos-ui-* package's postinstall script). Then we start the X11 server (for Hildon) or Wayland compositor (kwin for plasma-mobile, Weston) in an /etc/profile.d/ script, that checks if the current tty is the one where the autologin happened.

While that works for installing one device, it is not possible to cleanly switch out user interfaces after the installation (because replacing the entry in the inittab does probably not work when switching), and it is not possible to install multiple user interfaces in parallel and switch dynamically.

Our requirements for a display manager, as I see it:

  • Needs to be able to execute X11 UIs (desktop environments) as well as Wayland compositors (!)
  • It should set up the login session (consolekit?) and udev stuff (as @MartijnBraam suggested)
  • It should be lightweight, so we don't blow up the image with something that could be done in a few MB (like the osk-sdl)
  • A config file, that selects the current UI would be nice as first step
  • Super fancy version with UI (future!)

    • if only one UI is installed, it should boot that

    • user can select the UI with touch buttons

    • display date, time and battery

    • reboot and power-off buttons

In my opinion, we don't need to allow multiple users for now, or typing in a password (as we focus on security and have full disk encryption anyway, and getting multi-user secured is hard).

It might be possible to use an existing display manager for that. However, the big difference is, that for our use case we don't need focus on user selection, but on selecting the session. On the other hand, we have a nice stack with osk-sdl already, with which touchscreens work across all these strange drivers, so it would be relatively easy to re-use that.

architecture enhancement future

Most helpful comment

Hi,

The sddm developers did not really like that I added some extra code to handle CK2 instead of rearchitecting the whole thing. I was actually pleasantly surprised that they would rather do it right than do it easy.

I haven't had the time rewrite that subsystem yet though, so that is why it isn't merged.

Yes, we (Ad茅lie) ship the patched version right now because it works. It doesn't work _well_, but it works. (There's a few oddities in some places. I'd like to investigate them further. I think they relate more to Plasma than sddm, though.)

I wouldn't upstream it to Alpine until it was properly fixed and accepted upstream.

All 8 comments

It would be nice to at least leave an option open to allow multiple users in the future. It might not be useful on phones and smartwatches, but it is on tablets and smart TV's. Although I guess the focus should still be on DE selection at that point. Or we could even make it so that the DE choice is remembered per user.

All future stuff though, let's focus on DE switching first.

The simplest implementation I know of is nodm which is X only and single user/single DE (built for mobile devices), its just a shell script so maybe we can extend that to support what we want.

This one? Well, it's not just a script, but it seems pretty minimal which is good. Implementing Wayland support should be our first priority then I guess.

What about Qingy?

qingy is a replacement for getty. Written in C, it uses DirectFB to provide a fast, nice GUI without the overhead of the X Windows System. It allows the user to log in and start the session of his choice (text console, gnome, kde, wmaker, ...).

http://qingy.sourceforge.net/

It sounds nice, however the last commit to it was in 2011. That commit also had the description "Setting ConsoleKit support to NO by default", and some before it mention only initial ConsoleKit support.

It's nice that Qingy it is based on DirectFB though, maybe it makes sense to fork it (and add touch screen support).

Meanwhile, @awilfox is porting sddm for Ad茅lie (a distribution, that is now based on Alpine) and will probably stream it up to Alpine too. SDDM is a bit heavier through its QT dependencies (compared to directfb), but it supports X11 and Wayland, and when the port is done, it will also work with ConsoleKit. So this sounds like an easy solution where we don't need to do any programming 馃帀

(While I have not tested it, I assume that through QT it has decent touch screen support already.)

@awilfox: If I understood correctly, Adelie is already shipping a patched sddm, and that patch has been merged into sddm's develop branch (but the PR is still open?). Do you happen to have planned to upstream this particular package any time soon to Alpine? (I know you have enough to do already, just asking if you were planning to do this soon anyway.)


@MartijnBraam successfully uses lxdm with i3 on the N900 so I was wondering if it made sense to use that for all UIs we have right now, to replace the ugly login hack. But while I'm researching this right now I realize that lxdm can't handle Wayland session (in contrary to sddm), so that won't work.

Hi,

The sddm developers did not really like that I added some extra code to handle CK2 instead of rearchitecting the whole thing. I was actually pleasantly surprised that they would rather do it right than do it easy.

I haven't had the time rewrite that subsystem yet though, so that is why it isn't merged.

Yes, we (Ad茅lie) ship the patched version right now because it works. It doesn't work _well_, but it works. (There's a few oddities in some places. I'd like to investigate them further. I think they relate more to Plasma than sddm, though.)

I wouldn't upstream it to Alpine until it was properly fixed and accepted upstream.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

schvabodka-man picture schvabodka-man  路  6Comments

ata2001 picture ata2001  路  4Comments

ata2001 picture ata2001  路  3Comments

cmdr2 picture cmdr2  路  7Comments

craftyguy picture craftyguy  路  7Comments