[PATCH xinit 2/3] startx: Under Linux start X on the current VT

[Jasper St. Pierre]

On Tue, Mar 25, 2014 at 10:02 AM, Hans de Goede <hdegoede at redhat.com> wrote:

> Hi,
>
> On 03/25/2014 02:50 PM, Julien Cristau wrote:
> > On Tue, Mar 25, 2014 at 12:56:35 +0100, Hans de Goede wrote:
> >
> >> When we let X allocate a new VT, systemd-logind will not recognize any
> >> processes running on this VT as belonging to a valid session (since
> there
> >> was no pam session opened on that tty).
> >>
> >> This causes problems like PolicyKit denials for these processes.
> >>
> >> ConsoleKit under Linux has been deprecated for a few years now and is no
> >> longer being maintained, so simply make this the default under Linux.
> >>
> > That sounds like a bad idea.  If people want policykit to be happy, they
> > should just use a display manager, IMO.
>
> Well people disagree:
> https://bugzilla.redhat.com/show_bug.cgi?id=806491
>

>From http://cgit.freedesktop.org/xorg/app/xinit/tree/startx.cpp:

XCOMM This is just a sample implementation of a slightly less primitive
XCOMM interface than xinit.  It looks for user .xinitrc and .xserverrc
XCOMM files, then system xinitrc and xserverrc files, else lets xinit choose
XCOMM its default.  The system xinitrc should probably do things like check
XCOMM for .Xresources files and merge them in, start up a window manager,
XCOMM and pop a clock and several xterms.
XCOMM
XCOMM Site administrators are STRONGLY urged to write nicer versions.

I assume we can't tell people who are still using startx in 2014 to just
stop using it?

> Sharing a VT between X and something else smells like trouble.
>
> It is not shared, X simply takes over the VT until startx exits again,
> and we've been doing this in Fedora for years without issues.
>
> Regards,
>
> Hans
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140326/2e24580f/attachment-0001.html>