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.
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.
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).
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 :-(.
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.
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.
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)
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.
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 :-).
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?
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).
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.
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
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).
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.
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.
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.
Thanks for working on this. In the meantime, can we get a gdm-2.20 repackaged for F11/F12? Thanks.
In Fedora 13 there's is no way to pass arguments to Xorg easely.
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.
I've filed an upstream bug about this, with a patch I have been using successfully for the last few weeks.
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
As far I I can tell, this still hasn't changed in fedora 13 or 14.
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.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Bug is still present in Fedora 16 as well as Rawhide.
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.
(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
So this is still an issue in GDM 3.2, right?
I'm pretty certain https://bugzilla.gnome.org/show_bug.cgi?id=586777 is the bug to follow if you're interested in this.
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.
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
As near as I can tell, a geologic epoch later, there is still no way to control server startup in gdm.
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.
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.
(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.
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.
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.
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.
FWIW, adding another upstream bugzilla entry. Reported in 2009, still sitting in the GNOME Bugzilla as "UNCONFIRMED".
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.
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).
I presume this is a lost case and this bug will never be fixed ?
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.
(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.
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
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
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
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
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.
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.
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?
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.
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.
Heck, this bug is now on the federal register of historical bugs. It would be a shame to close it now.
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.
Like I said before, this is on the federal register of historical bugs. Can't close it now.
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".
http://www.mitchellville.lib.ia.us/images/fj-10-anniversary-logo-cropped.png/image ;)
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
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.
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.
As far as I can see, gdm-3.38.1-1.fc33.x86_64 still cannot add user-defined X server command line options.
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.
If I am not mistaken, gdm-41.0-2.fc35.x86_64 still cannot pass arbitrary command-line options to the X server.
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.
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?
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.
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.
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.
just a couple more releases and we can close this as obsolete because Workstation won't support X any more! that's progress, right?
Still present in 39.