Hello Matt and Pekka, Actually, we are OK with running weston with a static tty within a systemd service file, but launcher_direct_connect() function is failing when user is not root.
Therefore, we patched weston to remove the expilicit check for root user. I am planning to send this patch to the mailing list. We also updated ownership of drm and tty devices accordingly, so that weston can run as non-root user. Best regards Emre Ucan Engineering Software Base (ADITG/ESB) Tel. +49 5121 49 6937 > -----Original Message----- > From: wayland-devel [mailto:wayland-devel- > [email protected]] On Behalf Of Matt Hoosier > Sent: Montag, 30. Oktober 2017 14:28 > To: Pekka Paalanen > Cc: wayland mailing list > Subject: Re: Automatically choosing a VT for DRM compositor? > > On Mon, Oct 30, 2017 at 5:10 AM, Pekka Paalanen <[email protected]> > wrote: > > > On Fri, 27 Oct 2017 09:10:02 -0500 > > Matt Hoosier <[email protected]> wrote: > > > On Fri, Oct 27, 2017 at 8:05 AM, Pekka Paalanen > <[email protected]> wrote: > > > > > On Fri, 27 Oct 2017 07:05:13 -0500 > > > Matt Hoosier <[email protected]> wrote: > > > > > > > HI Pekka, > > > > > > > > On Thu, Oct 26, 2017 at 2:06 AM, Pekka Paalanen > <[email protected]> > > > wrote: > > > > > > > > > On Tue, 24 Oct 2017 08:26:04 -0500 > > > > > Matt Hoosier <[email protected]> wrote: > > > > > > > > > > > On Tue, Oct 24, 2017 at 1:33 AM, Pekka Paalanen > <[email protected] > > > > > > > > > wrote: > > > > > > > On Mon, 23 Oct 2017 14:37:37 -0500 > > > > > > > Matt Hoosier <[email protected]> wrote: > > > > > > > > > > > > > >> It would be nice for non-session uses of Weston > (embedded > > > systems) if > > > > > > >> the controlling TTY didn't need to be manually supplied. > > > > > > >> > > > > > > >> Has anybody suggested using something like > VT_OPENQRY in the > > > > > > >> weston-launcher code to pick a TTY if one wasn't > manually given? > > > (Or > > > > > > >> if that's too auto-magic for taste here, then only do that > if a > > > > > > >> specific command-line option is supplied.) > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I do not recall such proposals. I'd like to hear more about > your > > > use > > > > > > > case. > > > > > > > > You're right in that Weston shouldn't care, but I would expect > the > > > > > system designer or administrator to care, usually. > > > > > > > > > > > > > I think that it would only typically be important if the designer > has > > > some > > > > use-case for actively hopping among more than one VT. That is, > at least, > > > > not my case. Weston is the only DRM user -- it just needs some > valid VT > > > to > > > > use. I would be interested to hear counterexamples though. > Are you > > > thinking > > > > that some program like Plymouth would get used early during > boot, and it > > > > would need to persist and occasionally show itself during the > main body > > > of > > > > the runtime? > > > > > > Nope. My rationale is simply: if you don't care which VT is being > used, > > > why not hardcode tty0 in a systemd unit and be done with it? > > > > > > > I appreciate that though. In practice, it's difficult to guarantee > that > > there won't be some transient early splash type program squatting > on the > > first TTY which is just waiting to die until somebody comes along > and > > VT_ACTIVATE's away from it. > > > > I hope that doesn't sound like a bait-and-switch argument. I'm not > denying > > that there may be some random little graphical program that uses > VT's. My > > claim is just that these are usually not relevant to the main runtime > of > > the system. Once Weston get running, it owns the foreground > graphics > > permanently. > > > Hi, > > I'm afraid that sound quite much like you don't actually know what > runs > in the (embedded) system you are developing. > > > > For any one specific device, I do do know the fine-grained details. The > logistical trouble is in trying to harmonize the Weston configuration across > numerous devices (from different chip vendors), all of which differ in ways > which (to me) seem incidental. There is always a surplus of VT's compared to > the zero (or one) early-boot users of DRM, so it doesn't cause me much > worry that Weston will fail to select an available TTY. > > It seems like there's a small mismatch of expectations. The existing weston- > launch implementation already uses VT_OPENQRY to select whatever free > VT happens to be available, if you do 'weston-launch -u <new_user>'. I'm not > really seeing the reason for that being okay, but regarding similar automatic > selection in the direct launcher as sloppy design. > > > > > > > I think I'd just like to float the original question again: would > anybody > > > > be receptive to a very limited patch that does nothing more > than narrowly > > > > allow Weston to survive the TTY selection phase in the absence > of any > > > > external hint such as --tty=, logind, or being spawned from a > process > > > whose > > > > stdin is already a VT? > > > > > > > > If that seems contrary to the direction you'd like to take > Weston, that's > > > > okay. It's not a huge burden to do explicit TTY selection at > > > system-design > > > > time. That just seems a bit unnecessary for devices whose only > raw DRM > > > user > > > > is Weston. > > > > > > If someone writes the patch and someone else reviews and lands > it, I > > > suppose I'm ok with that. We have two non-logind launchers: > direct and > > > weston-launch the suid binary. > > > > > > > I'll volunteer to be the first 'someone'. Maybe I can convince > daniels to > > be the second. ;) > > > > Because the weston-launch approach is centered around the > notion of > > executing from some session, I think I'd be inclined not to touch > the suid > > binary. Do you think that would be objectionably unsymmetric? > > Does this mean you would only cater for the "run weston as root" > case? ;-) > > > > No, that wasn't the intent. Running a DRM instance of Weston as a non-root > user doesn't require anything really more than adjusting ownership on the > /dev/tty* character devices so that the VT can be configured. I.e. a user > 'weston' would need added to the 'tty' Unix group to have permission to run > ioctl(/dev/tty0, VT_OPENQRY) and would also need assigned ownership of > /dev/tty[0...7] in order to do KDSETMODE. Nobody would want to do that on > the desktop because of the security implications, but that seems fine to do > on an embedded system. > > > > If the aim is to make it easier to test during development, that's fine > by me. But if the aim is to use that for production, then I'd be > disappointed. Of course, we cannot know what people will use it for. > > I don't think I could NAK the patch only because of adding > differences > between the launchers. > > > > > Okay, I appreciate that. If you find the replies (including the bit about > VT_OPENQRY already getting used in weston-launch) above unconvincing, > let's just drop the thought then. > > > > > > > I do know people have struggled with starting weston via ssh or a > > > serial terminal. Would this make that simply work? I think that > would > > > be a good justification. > > > > > > > Yes, serial and ssh terminal usage is (in addition to formal systemd > usage) > > one of the clunky situations that demands the --tty command line > option > > right now. This is typical for iterative development of Weston on > embedded > > devices. And because the preceding instance of the Weston > process may well > > have crashed and not cleaned up the VT it was on, you always have > to be > > changing the value of that --tty parameter. Automatic selection > would be > > extremely convenient for this case too. (Note, I'm not talking about > > unbounded growth in the numeric value of the -tty= parameter. > Just toggling > > back and forth between '1' and '2', for example.) > > Right, so this is the underlying true reason for the suggestion. > > > > Well, as I said above in the thought about making it less difficult to deploy > Weston across a fleet of devices which have varying configurations of other > small DRM/VT programs, this is just an additional reason. I don't deny the > usefulness during development too though. > > > > Does something eventually clean up the VTs where weston/direct > crashed, > or will you run out of VTs soon? > > > If you did not run weston directly as root, then there would always > be > something, either weston-launch or logind, to reset the VT to a sane > state, I believe... weston-launch should, I presume logind as well? > > > > > OTOH, I would always recommend relying on logind if it is present > in a > > > system because that is the most appropriate way to use weston: > logind > > > handles the privilege separation, session multiplexing, revoking > input > > > devices and DRM master, etc. However, I have no idea how to > launch with > > > logind via ssh or serial aside from writing a systemd service unit. > > > > > > I wonder, if VT_OPENQRY picks, say, tty2, and then Weston VT- > switches > > > there, does something prevent it from clashing with the getty > that > > > systemd would launch there on the first switch to tty2? Or is it a > > > non-issue? > > > > > > > > > I'm not certain about that. In order to prevent ugly text console > prompts > > from appearing transiently on-screen prior to Weston's launch, I (as > the > > system designer) typically mask all getty@ unit instances which > would > > operate on VT's. > > I was more thinking about input devices. The launchers intend to > block > input from the TTY when weston starts, but there have been issues > where > it somehow failed and when you typed in a weston session the same > typing would go into the TTY (text login, shell, ...) as well. > > > Thanks, > pq > > > > Cheers, > Matt _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
