Bug 91421

Created attachment 117289 [details]
The minimalist xorg.conf that currently works with r128 x.org DDX device driver

This is the fewest lines I have gotten it to.
I may be able to get rid of "Load  "glx"" line (Line 3), but it will be nice if the use of xorg.conf can be optional for a default (device driver automatic configuration) use.

By demanding xorg.conf, the code is being hostile to the user. But by buying an r128 card, the user is being hostile to himself. I'm not aware of any UMS drivers actually having this feature (OpenChrome can do UMS and KMS). Porting the r128 kernel module to KMS is still something on my todo list, so I'd rather wait until then.

Created attachment 117396 [details]
The shortest xorg.conf I got r128 x.org DDX device driver to work with Ubuntu 10.04

This is the The shortest xorg.conf I got r128 x.org DDX device driver to work with Ubuntu 10.04.

Created attachment 117397 [details]
Xorg.0.log when I booted Ubuntu 10.04 with the shortest xorg.conf I got so far

(In reply to Connor Behan from comment #2)

I attached an even more minimalist xorg.conf to this bug report.
Please note that I was able to boot Ubuntu 10.04 successfully with that xorg.conf.
I think if the DDX device driver can assume a default DRI mode, then that portion can be eliminated from xorg.conf.
Is there also a way to get X server to pick the correct device driver for the graphics card it has identified?
If this is possible, then 'Identifier  "Card0"' portion can be eliminated.
I feel like the device driver is very close to being able to operate without xorg.conf.
    Generally speaking, the computing industry has moved towards automatic settings in the past 20 years (i.e., Plug & Play was a big deal with Windows 95), so eliminating the necessity to use xorg.conf should be considered.
Of course, it is okay to provide an option to override the default settings,  but at least the device driver should be designed in a way to be able to operate without a settings file.
That is why I filed this bug report in the first place.
As I have shown, the device driver itself is very close to being able to operate without xorg.conf, and besides, it used to be able to operate without xorg.org around 2010.


> By demanding xorg.conf, the code is being hostile to the user. But by buying
> an r128 card, the user is being hostile to himself. I'm not aware of any UMS
> drivers actually having this feature (OpenChrome can do UMS and KMS).
> Porting the r128 kernel module to KMS is still something on my todo list, so
> I'd rather wait until then.

(In reply to Kevin Brace from comment #5)
> (In reply to Connor Behan from comment #2)
> 
> I attached an even more minimalist xorg.conf to this bug report.
> Please note that I was able to boot Ubuntu 10.04 successfully with that
> xorg.conf.
> I think if the DDX device driver can assume a default DRI mode, then that
> portion can be eliminated from xorg.conf.

I think that will require DRI changes beyond just what is in the DDX. DRI1 is dead right now, so getting the driver to stop using that (long term) is a better plan.

> Is there also a way to get X server to pick the correct device driver for
> the graphics card it has identified?
> If this is possible, then 'Identifier  "Card0"' portion can be eliminated.
> I feel like the device driver is very close to being able to operate without
> xorg.conf.
>     Generally speaking, the computing industry has moved towards automatic
> settings in the past 20 years (i.e., Plug & Play was a big deal with Windows
> 95), so eliminating the necessity to use xorg.conf should be considered.
> Of course, it is okay to provide an option to override the default settings,
> but at least the device driver should be designed in a way to be able to
> operate without a settings file.
> That is why I filed this bug report in the first place.
> As I have shown, the device driver itself is very close to being able to
> operate without xorg.conf, and besides, it used to be able to operate
> without xorg.org around 2010.

I really don't know why X cares so much about "Card0" being present. If you can find the specific 2010-era commit where this changes occurred, I'd be interested.

[Likely off-topic.] Following what I've discussed on bug 91622, the iMac G3 will unfortunately always require an xorg.conf since there is no DDC/EDID for the internal display. The way Apple gets these monitors working with their OSes is likely through detecting the model via firmware; such a detection is probably beyond the scope of an xorg driver, let alone UNIX philosophy.

The other way of getting such models to work "out of the box" would likely be a third party utility that performs such a detection and applies the appropriate xorg.conf.

Kevin Brace, Ubuntu 10.04 Desktop reached EOL on May 9, 2013. For more on this, please see https://wiki.ubuntu.com/Releases .

If this is reproducible in a supported release, it will help immensely if you filed a new report with Ubuntu by ensuring you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information running the following from a terminal:
ubuntu-bug xorg

Also, please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.

This is not an Ubuntu bug tracker...

(In reply to Connor Behan from comment #9)
> This is not an Ubuntu bug tracker...

Thanks for that, but I am already aware.

Despite this, given the original reporter originally reported with an insecure/EOL OS as previously documented, hasn't posted anything on a supported release, and hasn't posted for 6+ months, it doesn't seem a great idea to encourage folks to use software that will endanger the data security of their system, and those around them. Let alone, burdening upstream with a downstream software support request.

However, as you have a different take here, I'll leave this report as you like.

Thanks, those are all valid points. However, with this particular issue, I can confidently say that the OP will experience it no matter which distro he uses as long as the monitor doesn't change.

I don't have strong feelings about keeping this bug open. The main reason I might want to refer to it is because of the astute comment by Chavez above which explains why the need for manual configuration is the fault of certain vendors and not Xorg developers :).

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-r128/issues/5.