Bug 451562 - no way to control X server startup options
Summary: no way to control X server startup options
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 39
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-06-15 20:49 UTC by Tom Horsley
Modified: 2023-11-23 06:58 UTC (History)
30 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 738462 (view as bug list)
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)
Patch to add X options to /etc/gdm/ (2.46 KB, patch)
2015-10-28 00:31 UTC, Jay Hilliard
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 586777 0 Normal RESOLVED Allow specifying how local X server is started 2021-02-19 04:03:47 UTC
GNOME Bugzilla 632045 0 Normal RESOLVED gdm does not allow configuration of X server arguments 2021-02-19 04:03:47 UTC

Description Tom Horsley 2008-06-15 20:49:50 UTC
Description of problem:

There is either no way to change the options gdm starts the X server
with, or the way to do it has been granted the protection of the
total obfuscation Gods.

I would like to add the -dpi 96 option to the X server to induce the
login app to show up with fonts big enough to be visible.

In other situations I have trusted machines behind a firewall, and I'd
like to remove the -nolisten tcp option.

Both these goals seem to be absolutely impossible to achieve without
employing desperate measures like replacing the X server with a program
that diddles the options then execs the original server (a scheme that
won't survive the first update of X :-).

Version-Release number of selected component (if applicable):
gdm-2.22.0-5.fc9.x86_64

How reproducible:

100%

Steps to Reproduce:
1. try to find how to control server start options
2. pull hair
3. sit in corner drooling
  
Actual results:
No way to influence options

Expected results:
Some way to influence options

Additional info:
I know for a fact I've been able to get rid of the -nolisten tcp
option in the past.

Comment 1 Tom Horsley 2008-08-04 20:53:31 UTC
By the way, I tried adding a "Monitor" section with a DisplaySize
directive giving the size which would cause it to compute 96dpi,
but X is so proud of finally using the EDID info after ignoring
it for 20 years that it apparently utterly ignores DisplaySize,
so I can't induce it to calculate 96dpi by lying about the size.

Comment 2 Arlinton Bourne 2008-08-30 22:15:23 UTC
I've run into this issue as well. The fix is not to mess with any of the X server configurations, but to mess with gconf configurations. 

Since gdm is run by the user gdm editing:
~gdm/.gconf/desktop/gnome/font_rendering/&gconf.xml

modify the line whose entry's name is:

name="dpi"

and change the value to your desired DPI:

value="72"

the line in the file should look something like this:
<entry name="dpi" mtime="xxxxxxxxxxx" type="float" value="72">

(the mtime is totally invalid in this example).

Comment 3 Tom Horsley 2008-08-30 23:43:00 UTC
By golly that worked! I just copied the xml file from my users
.gconf/desktop/gnome/font_rendering directory to the gdm users
directory and chown gdm:gdm everything, and it now provides a
login prompt I can actually read :-).

Still can't get rid of the -nolisten tcp option though :-(.

Comment 4 william hanlon 2008-09-22 19:06:23 UTC
I'd like to see some documentation on how to fix this as well. I use applications that depend on backing store and in previous Fedora releases I'd edit add the +bs option in the call to the Xserver. In the past I'd edit /etc/gdm/gdm.conf which had the line (or an example) to edit, now that file is gone. It seems custom.conf is similar to the gdm.conf, but there's no example or documentation of how to accomplish the task.

Comment 5 Tom Horsley 2008-12-10 17:49:27 UTC
Well, I still have no clue how to add arbitrary options to the server startup,
but I did finally determine that I can add the DisallowTCP parameter to the
security section of /etc/gdm/custom.conf to disable the -nolisten tcp argument.

The section looks like this in /etc/gdm/custom.conf:

[security]
DisallowTCP=false

I had to resort to digging through the gdm source code to dig this up,
and I have to say, I wouldn't expect a team of 10,000 PhDs working
night and day to be able to obfuscate code any more successfully
than gdm code is obfuscated. How anyone can complicate the task of
asking a user one question to decide if he should get logged in or
not is utterly beyond my comprehension (and I hope it always remains
out there :-).

I also found that merely doing a Ctrl-Alt-Backspace doesn't restart
enough stuff for this change to take effect, but rebooting does
take care of it.

Comment 6 J Gallagher 2008-12-12 14:51:17 UTC
You can hack the gdm binary and add some custom settings, you'll need to replace the -verbose parameter though so messages will be hit

sed 's/verbose/dpi 96 /g' -i /usr/libexec/gdm-simple-slave

the relevant section in the source-code is in daemon/gdm-server.c, "-nr -version" are hardcoded parameters, why can't the code read from a config file here and allow users to pass their parameters of choice.

This is a pretty bad bug btw, since on netbooks gdm font is far too big (the session selector Gnome/KDE is barely displayed becasue of lack of space)

Comment 7 QingLong 2009-01-11 12:51:56 UTC
The problem actually is much bigger and the reason is much deeper.
The reason seats in the heads of Fedora developers:
they are trying to turn *nix OS into micro$oft-like lamer-friendly bullshit.
This is going everywhere in the distribution,
the system is not controlled by the user anymore,
instead the system tries to fucking lecture user how to think.
Looks like Fedora (or RedHat?) headquarters is located in Redmond now.

Comment 8 Tom Horsley 2009-02-23 23:55:38 UTC
Hey, more information for users of the closed source nvidia driver. You
can actually browbeat it into setting the DPI to the value you want. In
the "Device" section of xorg.conf, I added:

	Option      "UseEDIDDpi" "False"
	Option      "DPI" "96 x 96"

This seems to globally force the use of 96dpi, but, of course, in a
device driver specific fashion, which is kind of obnoxious. Found these
in the html docs installed in /usr/share/doc/xorg-x11-drv-nvidia-180.29/.

Not sure how long they have been supported (I'm pretty sure I looked
back when I first added this bug, but maybe I missed them).

Using DPI from the EDID information really does seem to be an incredibly
bad idea in general. Not only does it produce ridiculous sized fonts
even when it is accurate for large monitors, but my new Samsung HDTV
simply reports 160 x 90 mm to get the aspect ratio right and doesn't
even make an attempt to give the right DPI (which would be more like
1018 x 573 mm if it did give an accurate value). In the Samsung
case instead of getting microscopic fonts, I get fonts so large that
most dialog boxes don't fit on the 46 inch screen :-).

Comment 9 Hans Ulrich Niedermann 2009-02-28 09:55:46 UTC
DPI settings aside, there are other X server startup options one might want to add. Example: "-logverbose 7".

There appears to be a server->priv->session_args variable which can be used to add arguments to the X11 server command line, but there appears to be no way to at all to set those session_args:

[gdm-2.24.1]$ grep -r session_args *
daemon/gdm-server.c.force-active-vt:        char    *session_args;
daemon/gdm-server.c.force-active-vt:        g_shell_parse_argv (server->priv->session_args, &count, &args, NULL);
daemon/gdm-server.c.force-active-vt:        if (server->priv->session_args) {
daemon/gdm-server.c:        char    *session_args;
daemon/gdm-server.c:        g_shell_parse_argv (server->priv->session_args, &count, &args, NULL);
daemon/gdm-server.c:        if (server->priv->session_args) {
[gdm-2.24.1]$

This is Fedora 10, using gdm-2.24.1-4.fc10.i386.

Is there any way I can add -logverbose 7 to my Xorg command line without patching gdm?

Comment 10 Tom Horsley 2009-02-28 11:56:07 UTC
If you just need logverbose one time to choke some extra info out of
the X sever, I think you can still add options when you start using
the startx command rather than letting gdm start things, so you might
be able to switch to runlevel 3 and start X with startx (though I forget
the exact syntax for passing options along to X).

Comment 11 Hans Ulrich Niedermann 2009-02-28 12:21:28 UTC
I need "-logverbose 7" in everyday use so I can find out what has been going on and going wrong during that exact everyday use.

If it was just for one-off Xorg start, I'd just run "Xorg :5 -logverbose 7" from a root console login and Ctrl-Alt-Backspace it a few seconds later to examine /var/log/Xorg.5.log.

Comment 12 Bug Zapper 2009-06-10 01:38:16 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 13 Tom Horsley 2009-06-10 01:46:32 UTC
This situation has not changed. gdm is still hopeless even in f11
(which is why I switched to kdm where I can simply edit ServerArgsLocal
in the /etc/kde/kdm/kdmrc file). Of course it takes a ridiculous quest
to discover that file and the option in it, but at least you can eventually
find it (unlike gdm).

Comment 14 Peter Åstrand 2009-07-08 11:07:59 UTC
I'm also suffering from this problem. For example, when using VirtualGL, it's pretty important to add the "-tst" argument, but with current gdm, this is impossible. This needs to be fixed.

Comment 15 Jan "Yenya" Kasprzak 2009-11-18 11:51:03 UTC
Still present in F12, gdm-2.28.1-24.fc12.x86_64 - unles some kind of magical way of controlling the X server options has been added, which I could not find.

GDM is still completely unusable in multi-seat configurations because of this.

Comment 16 Ray Strode [halfline] 2009-11-18 16:05:17 UTC
I've been working Halton Huo and Brian Cameron from Sun Microsystems to get a configurable, multi-seat aware GDM ready.

It's progressing slowly, but should be in gnome 2.30.  See the gdm-list and ConsoleKit list mailing list archives for more details.

Comment 17 Jan "Yenya" Kasprzak 2009-11-18 16:13:47 UTC
Thanks for working on this.

In the meantime, can we get a gdm-2.20 repackaged for F11/F12? Thanks.

Comment 18 scumbag 2010-05-24 21:54:29 UTC
In Fedora 13 there's is no way to pass arguments to Xorg easely.

Comment 19 Roger Wells 2010-08-18 16:52:54 UTC
re Comment # 18
This is a big problem.  I can't believe that this is so hard but apparently it is.  Are the remarks in comment 7 true?  Everything in *nix is always configurable.

Comment 20 Dan Callaghan 2010-10-23 02:37:27 UTC
I've filed an upstream bug about this, with a patch I have been using successfully for the last few weeks.

Comment 21 Bug Zapper 2010-11-04 11:52:41 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 22 Tom Horsley 2010-11-04 12:14:24 UTC
As far I I can tell, this still hasn't changed in fedora 13 or 14.

Comment 23 Chris 2011-02-11 19:35:01 UTC
Argh, just spent 2 days trying to find how to start gdm on tty1 (amongst other tweaks I'd like to make) and finally found this bug, so clearly it's not just me.

I had found various useful options documented on the gnome site but they weren't working. It seems a lot of the configurability was removed around GDM 2.20-2.22.
To their credit, the docs do explain this...

http://library.gnome.org/admin/gdm/stable/overview.html.en

However it does seem ridiculous that GDM is so inflexible. I've tried on Fedora 12 through to 14 and nothing seems to have changed.

Comment 24 Fedora Admin XMLRPC Client 2011-06-21 15:32:52 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 25 Fedora Admin XMLRPC Client 2011-06-21 15:36:13 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 26 Fedora Admin XMLRPC Client 2011-06-21 15:37:35 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 27 Fedora Admin XMLRPC Client 2011-06-21 15:40:50 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 28 Fedora Admin XMLRPC Client 2011-06-21 15:50:21 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 29 Fedora Admin XMLRPC Client 2011-06-21 15:52:56 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 30 Fedora Admin XMLRPC Client 2011-06-21 15:55:24 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 31 Fedora Admin XMLRPC Client 2011-06-21 15:56:36 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 32 Benny Amorsen 2011-11-24 20:14:02 UTC
Bug is still present in Fedora 16 as well as Rawhide.

Comment 33 Jan "Yenya" Kasprzak 2011-11-24 20:27:53 UTC
Yep. The workaround which has worked for me was to abandon the whole gdm thing and use xdm instead. Xdm just works(tm), and allows you to set everything you need.

Has anybody got multiseat working with anything other than xdm?

There is even a Feature/Multiseat page on Fedora wiki:
http://fedoraproject.org/wiki/Features/Multiseat
last updated in 2009, but there has been no progress in _years_.

In the meantime, there are people out there (like me), who use multiseat with Fedora on a regular basis, and it works. You have just say no to all the *kits, GNOME 3, gdm, etc., and use sane UNIX(r) tools like xdm.

Apparently gdm devs are focused on making gdm pretty instead of making it work.

Sorry for the grumpy comment, but having this "bug" (in fact a misfeature of the gdm-2.22 rewrite) unfixed since mid-2008 says something about the attitude of gdm (and GNOME) developers.

Comment 34 Piergiorgio Sartor 2011-11-26 19:12:45 UTC
(In reply to comment #33)
[...]
> Apparently gdm devs are focused on making gdm pretty instead of making it work.

This seems a general attitude at freedesktop, unfortunately.

> Sorry for the grumpy comment, but having this "bug" (in fact a misfeature of
> the gdm-2.22 rewrite) unfixed since mid-2008 says something about the attitude
> of gdm (and GNOME) developers.

You have my support, for what it could count...

bye,

pg

Comment 35 Leho Kraav 2012-04-20 01:05:53 UTC
So this is still an issue in GDM 3.2, right?

Comment 36 Leho Kraav 2012-04-21 22:30:58 UTC
I'm pretty certain https://bugzilla.gnome.org/show_bug.cgi?id=586777 is the bug to follow if you're interested in this.

Comment 37 Dmitry Bolkhovityanov 2012-11-27 10:42:24 UTC
Regular RHEL-6.3 -- the same problem.
Hey, guys -- this seems ridiculous. While Fedora might need such eye-candy as "fade" (--force-active-vt), regular Linux requires an ability for X-server options to be administrator-controllable.

Current approach, when LOTS of stuff are hardcoded in gdm sources, is unbearable.

Comment 38 Fedora End Of Life 2013-01-16 22:12:55 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 39 Tom Horsley 2013-01-16 23:27:58 UTC
As near as I can tell, a geologic epoch later, there is still no way to control server startup in gdm.

Comment 40 Leho Kraav 2013-01-16 23:29:37 UTC
I'm running gdm-3.6.2 now almost everywhere.. but the box that this issue most bothers me on. So definitely still keeping an eye on this.

Comment 41 Jan "Yenya" Kasprzak 2013-01-17 10:48:45 UTC
Yep, me too. My multiseat system is still running xdm as I describe in comment #33. Also, the comment #16 looks funny after 3+ years.

Comment 42 Matěj Cepl 2013-01-17 11:57:32 UTC
(In reply to comment #41)
> Yep, me too. My multiseat system is still running xdm as I describe in
> comment #33. Also, the comment #16 looks funny after 3+ years.

I guess part of the explanation is in the comment itself ... "from Sun Microsystems", but yes I am sorry for the state of this bug.

Comment 43 Kjetil T. Homme 2013-01-29 19:09:02 UTC
the issue which brought me here is that I'd like to reduce the -audit 4 to something more reasonable, like 1 or 0.  but this option seems hardcoded in the gdm-simple-slave binary, and it is not clear to me how I can work around it.

Running gdm 2.30.4 on RHEL6.

Comment 44 Fedora End Of Life 2013-12-21 08:22:14 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 45 Tom Horsley 2013-12-21 12:48:18 UTC
As near as I can tell, this has never been fixed. It would be a shame to close such a historic bug with such a long history. Changing to fedora 20.

Comment 46 Jan "Yenya" Kasprzak 2014-01-02 16:12:36 UTC
FWIW, adding another upstream bugzilla entry. Reported in 2009, still sitting in the GNOME Bugzilla as "UNCONFIRMED".

Comment 47 Fedora End Of Life 2015-05-29 08:35:12 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 48 Tom Horsley 2015-05-29 10:27:48 UTC
No! This bug is on the federal register of historic bugs! You can't close it now. Changing to fedora 22 (where, of course, it is still busted).

Comment 49 bkramer 2015-08-12 11:26:40 UTC
I presume this is a lost case and this bug will never be fixed ?

Comment 50 Vincent S. Cojot 2015-08-12 12:24:38 UTC
Should we open a clone of this bug against RHEL6/RHEL7?
This feature would still be needed there..

Just a few weeks ago I discovered a regression in the backingstore implementation of the regular Xserver in RHEL6.7 and opened a bugzilla about it.
I would have wanted to start the X server on RHEL6.7 with different options to verify that '-bs' was a workaround but I found no easy way to do this.

This could be something like /etc/sysconfig/xserver on EL distribs.

Comment 51 Tom Horsley 2015-08-12 13:08:33 UTC
(In reply to Vincent S. Cojot from comment #50)
> Should we open a clone of this bug against RHEL6/RHEL7?
> This feature would still be needed there..

Or just drop gdm and use a different login manager by default. As far as I know all the other alternatives have perfectly fine (if hard to discover) methods for controlling the server options.

Comment 52 Vincent S. Cojot 2015-08-12 14:36:30 UTC
Hi Tom,
I already provide an alternate Login Manager along with OWacomp in the OWacomp-slim rpm's. However, it would be nice if we didn't have to replace the Login Manager for trivial stuff like starting X with different Xserver(1) options or to provide an alternate windowing environement (it was the only was I figured to let the user start a non-KDE, non-GNOME env..)
I think I'll file a copy of this bug against RHEL6 (unless there is one already).
My 2c,
Vincent

Comment 53 Jay Hilliard 2015-10-28 00:31:57 UTC
Created attachment 1087110 [details]
Patch to add X options to /etc/gdm/

To Use the patch to override X options in /etc/gdm/custom.conf

[x]
Xoptions=-audit 0 -logverbose 5

Comment 54 Jay Hilliard 2015-10-28 00:33:56 UTC
For RHEL6, I have used this patch for some time. It applies cleanly to gdm-2.30.4-64.el6.src.rpm. Is there a way to set Xorg options on RHEL7?

I've attached gdm-xoptions.patch in case anyone wants it.

# allow configuration options that pass to X
Patch200: gdm-xoptions.patch
%patch200 -p1

Comment 55 Vincent S. Cojot 2015-10-28 13:57:52 UTC
Hi Jay,
Thanks for the patch. It is indeed clean and simple.
Do you try submitting it upstream? I wonder why it's not included by default.
Regards,
Vincent

Comment 56 Ray Strode [halfline] 2015-10-28 14:53:17 UTC
we've been hesitant to include that sort of feature in GDM because:

1) GDM requires certain options to function (say using -terminate could cause hard to debug problems or passing a display in manually could cause problems. Other options have security implications, too.), so it would be fragile and finicky.  The user could make a change and all of a sudden things would break.

2) The X server is started with different options in different situations (-seat is sometimes passed, for instance.  We need control over the options since we need to be able to change them depending on the reason we're starting the X server.

3) Users don't want to pass options just for the sake of it, they're obviously trying to get specific behaviors.  It's a means to an end, but often we can provide those behaviors as independent options, or just change the defaults to accommodate what the user wants instead.  For instance, we enable listening on tcp sockets when Xdmcp is enabled.  We automatically up log verbosity if the user enables Debug.  So there are "better" ways of giving the user the flexibility they require without adding an option that can change how X is started in a way GDM isn't expecting.  It's better to keep GDM in the loop from a reliability standpoint.

Comment 58 Jan "Yenya" Kasprzak 2015-10-28 21:31:53 UTC
Re: comment #56

Ray, thanks for your comment. It is really enlightening.

Yes, everything you write would hold _if_ the corresponding gdm option would be available at the same time a new X server option is added. This is definitely not what we see here. 7+ years and still counting. As you can see from the comments in this bug, Gdm developers do not really care what the users might want, when it is different to what GNOME developers expect them to want.

If the user wants to break his own system by adding the X server option conflicting to what gdm expects, it is his own problem. If the X server supports something that the user wants, and gdm does not allow the option to be passed to it, it definitely is the problem of gdm. And it has been for over 7 years.

Gdm should stop inventing its own way of wrapping individual X server switches, and accept the patch from comment #53.

Anyway, the real solution to this problem is to abandon gdm altogether, and use lightdm or xdm instead. Lightdm even supports GNOME-style chooser, for the masochists out there who still want to use GNOME.

Sorry for the harsh words, but 7+ years old unfixed bug with promised fixes all along the way (comment #16, for example) does not deserve anything nicer.

Comment 59 Jay Hilliard 2015-10-29 00:07:24 UTC
Any method that allows me to pass "-audit 0 -logverbose 5" is a good solution in my mind, given no alternatives offered by anyone to date. We don't pass options "just for the sake of it".  These settings allow the collection of serial number and other details about connected display devices from the Xorg log. Disabling Audit also prevents the logs from filling up the local disk over time.

Can anyone answer the question I asked in comment 54: Is there any way in RHEL7 to pass "-audit 0 -logverbose 5" to Xorg without patching gdm?

Comment 60 Ray Strode [halfline] 2015-10-29 13:30:42 UTC
If you put  

Enable=true

in the [debug] section of /etc/gdm/custom.conf

then the X server will be started with -logverbose 7 which should include the extra information you would like in the log. 

In Fedora, logs are stored in the journal, but in RHEL 7 they're stored in /var/log/gdm and the logs get rotated and capped to a specific number. You could probably set up logrotate to do more aggressive rotation if the gdm rotation isn't good enough.

I don't think the default audit level in rhel 7 should cause too much diskspace usage though. It adds a message per program start/exit. So it's something like a megabyte for every 10,000 programs run (assuming the log isn't rotated away before then, and the log likely would be rotated away long before then).

But if I'm missing something, and the X logs really are taking a non-negligible percentage of the disk in some real-world situations, then I wouldn't be opposed to adding an option to disable X auditing to the gdm config.  Failing that, maybe the X config file itself could expose the audit trail level as an option.  

In general, the X config file already comes with the expectation that changes to it can break the system, and it is the file meant for X configuration, so it may be a more appropriate place for hooking in configuration for certain things.

Anyway, we're on a bit of RHEL tangent here in a Fedora bug, since i don't think we up the audit trail level in Fedora at the moment.

Comment 61 Fedora End Of Life 2016-11-24 10:22:38 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 62 Tom Horsley 2016-11-24 11:05:35 UTC
Heck, this bug is now on the federal register of historical bugs. It would be a shame to close it now.

Comment 63 Fedora End Of Life 2017-11-16 18:43:17 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 64 Tom Horsley 2017-11-16 19:11:16 UTC
Like I said before, this is on the federal register of historical bugs. Can't close it now.

Comment 65 Jan "Yenya" Kasprzak 2018-06-17 09:45:06 UTC
Let us celebrate the 10th anniversary of this bug. Now it is officially part of the world heritage.

Of course, still present in F28 - gdm-3.28.2-1.fc28.x86_64. Also, keeping the status of this bug as "NEW".

Comment 67 Jan "Yenya" Kasprzak 2019-05-02 14:41:05 UTC
As far as I can see, there is still no way how to set the X server options from gdm in Fedora 30, so let me advance the Version: attribute of this historic bug by two.

gdm-3.32.0-3.fc30.x86_64

Comment 68 Jan "Yenya" Kasprzak 2019-11-07 07:51:14 UTC
Looking into gdm-3.34.1-1.fc31.x86_64, I still don't see how to add/set the X server options. Raising Version to 31.

Comment 69 Ben Cotton 2020-11-03 17:29:48 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 70 Jan "Yenya" Kasprzak 2020-11-06 09:53:20 UTC
As far as I can see, gdm-3.38.1-1.fc33.x86_64 still cannot add user-defined X server command line options.

Comment 71 Ben Cotton 2021-11-04 17:22:21 UTC
This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 72 Jan "Yenya" Kasprzak 2021-11-05 09:33:20 UTC
If I am not mistaken, gdm-41.0-2.fc35.x86_64 still cannot pass arbitrary command-line options to the X server.

Comment 73 Ben Cotton 2022-11-29 16:43:26 UTC
This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 74 Jan "Yenya" Kasprzak 2022-12-01 12:31:08 UTC
As far as I can tell, gdm-43.0-3.fc37 in Fedora 37 still does not allow to pass arbitrary command-line options to the X server.

It seems that I cannot bump a Version: tag to "37". Can somebody do this instead of me?

Comment 75 Tom Horsley 2022-12-01 13:09:00 UTC
I figured as the one who submitted this, I could bump the version, but if there is a way to edit the version anywhere on this bugzilla web page it is hidden too well for me to find it.

Comment 76 Adam Pribyl 2022-12-01 17:26:17 UTC
This bugzilla feature also drives me nuts - on the right side of the bug header there is a button "Show advanced fields". I bumped the version, anyway, nobody cares.

Comment 77 Aoife Moloney 2023-11-23 00:01:01 UTC
This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 78 Adam Williamson 2023-11-23 00:05:48 UTC
just a couple more releases and we can close this as obsolete because Workstation won't support X any more! that's progress, right?

Comment 79 Jan "Yenya" Kasprzak 2023-11-23 06:58:19 UTC
Still present in 39.


Note You need to log in before you can comment on or make changes to this bug.