Age | Commit message (Collapse) | Author |
|
Currently startx relies on /tmp/.X?-lock being present for automatically
picking a free display number. This does not work if -nolock is used when
starting the server, or if the server is started with -displayfd as -displayfd
implies -nolock.
This is becoming a problem now that -displayfd is getting used by
display-managers (e.g. gdm), this fixes this by also checking for
/tmp/.X11-unix/X?
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
This was Apple Computer’s implementation of the Unix operating system
for some of their Macintosh computers. From 1988 to 1995.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
Use the ':' operator instead of "match" and avoid the use of "\+". Both
constructions aren't specified by POSIX and not supported in BSD expr.
Also drop the '^' from the regular expressions as it is implicit and
POSIX leaves its behaviour undefined.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Matthieu Herrb <matthieu@herrb.eu>
|
|
Detaching from the tty causes systemd-logind to refuse service to the xserver,
the xserver already tries to detect that it is being asked to run on the
current tty and then automatically enables -keeptty, but this code fails if
all of stdin, stdout and stderr are redirected to a file. So explicitly tell
the xserver to not detach when we're telling it to run on the current tty.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1177513
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=83019
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Adding vtX to $defaultserverargs means that it will only be added when
the user specifies no server arguments.
This means that doing ie: "startx -- -depth 16" will cause the server to start
on a different vt then just "startx", which does not meat the principle of
least surprise.
Instead always pass the vtX argument, except when the user has specified its
own vtX argument. Note that vtX still only gets added for the default server,
since for ie Xnest or Xephyr it makes no sense.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: James Cloos <cloos@jhcloos.com>
|
|
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.
Note we do not pass in the vt if the user has specified an alternative server
to start, as the vtX argument is only valid for the Xorg server, likewise we
omit it if the user has specified any other server arguments.
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=806491
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
We don't support SCO / Unixware anymore, so lets remove the SCO / Unixware
specific bits from startx and xinitrc
SCO support was removed from the server in 2010:
http://lists.x.org/archives/xorg-devel/2010-December/017209.html
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Gaetan Nadon <memsize@videotron.ca>
|
|
being set
For some reason 'defaults' sometimes shows dpi in quotes and sometimes
doesn't.
Regression-from: 335937217a51e5e159a14463e0b1e3aedf35c6be
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
Unfortunately defaults has no way to check if a preference exists, and it
prints a message to syslog if we read one that doesn't exist. dpi is one
that commonly doesn't exist and results in user confusion when they read
syslog.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
Previously, we did not use the default values unless server or client weren't
set, but we should still use the defaults if they were not set but the server
was. This is most evident when you want to tell startx which server to use,
but you want startx to figure out which display to use automatically.
This fixes a regression introduced by the previous patch on XQuartz:
http://xquartz.macosforge.org/trac/ticket/523
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
Now everyone can benefit from this code that I previously added for darwin
https://bugs.freedesktop.org/show_bug.cgi?id=1789
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
It's used many other places than just for launchd.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
http://xquartz.macosforge.org/trac/ticket/399
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
id prefix (org.x is still default)
|
|
When startx fails to start X, it's most likely xinit that failed. xinit
returns a proper return code (1), but that gets clobbed in the startx
script by clean-up commands. This patch saves $? from xinit and forces
startx to exit with that value.
This way, if startx actually fails to start X, $? reflects that.
Signed-off-by: Andres Salomon <dilinger@debian.org>
|
|
|
|
with / or ./
If you invoke startx with a client whose initial command-line arguments
begin with / or ./, it uses the last such argument as the base command
for the client. E.g.:
startx /usr/bin/xterm /usr/bin/mutt
will use /usr/bin/mutt as the client to run instead of /usr/bin/xterm.
This is because of the way in which startx parses its arguments. It's a
loop over a case with three clauses; the bug is in the first. When it's
looking at one of startx's args it checks to see if $clientargs is empty
in order to see if it should set $client or add the argument to
$clientargs. It should also check to see whether $client is set.
There is a similar bug in parsing server args, where it checks to see if
$serverargs is empty to decide whether to set $server.
Debian bug#511717 (http://bugs.debian.org/511717)
Signed-off-by: Julien Cristau <jcristau@debian.org>
|
|
|
|
|
|
|
|
|
|
spaces in pathnames.
|
|
|
|
|
|
|
|
Per comments from Jeremy Reed on the list... basically doing for everyone what I do for Apple
|
|
/tmp/.X11-unix
|
|
Changing startx to work with this
|
|
|
|
|
|
if nolisten tcp was enabled.
|
|
else fall back to /dev/random.
Not doing in configure.ac because can't easily check for
existence when doing cross-builds.
(Alternative would be to define this for every operating system
in configure.ac. Currently only is defined for OpenBSD.
Systems that have mcookie also will not be effected.)
|
|
Quieted defaults "error" messages by initializing default values
Do font caching in startx, so users with custom ~/.xinitrc won't have to
worry about updating it.
Add "cache_fonts" defaults item to toggle whether or not to cache fonts at startup
Fall back on fc-cache if font_cache.sh is not present.
|
|
|
|
This should also fix this on SCO since it was using the incorrect BINDIR
instead of __bindir__ in that code block...
|
|
valid $display for fast-user-switching.
|
|
|
|
|
|
startx is advertised as a POSIX sh script. These shells don't
necessarily support trapping 'ERR'. This makes startx work again with
dash (and probably others).
|
|
|
|
|
|
Setting XAUTHORITY without having actually generated a cookie and created
.Xauthority led to issues if somebody like ssh later came around and made the
.Xauthority file for their own setup. So, simply make it so that we never
fail to create one.
|
|
terminating" errors with single quotes.
|
|
portable (for different /bin/sh shells) for the arithmetic.
NetBSD's /bin/sh didn't like: dummy=$((dummy+1)) and complained: startx:
arith: syntax error: "dummy+1"
This was fixed by NetBSD and also by Gentoo, see:
https://launchpad.net/distros/ubuntu/+source/xinit/+bug/31241
|