--- On Tue, 10/7/08, Chris Bredesen cbredesen@redhat.com wrote:
From: Chris Bredesen cbredesen@redhat.com Subject: F10 beta: No xorg.conf, where to tweak Synaptics pad? To: "Fedora List" fedora-list@redhat.com Date: Tuesday, October 7, 2008, 2:39 PM Hello List,
I'm on F10 (Dell D610 laptop) and so far it's gone very well. rhgb hangs but I shut that off anyhow.
I'm a bit confused about the Synaptics support. I'd traditionally had a large-ish xorg.conf that included all my Synaptics parameters making my touchpad useful.
F10 doesn't ship with an xorg.conf and it seems that the input hotplug facility now handles all of this. However, I can't find any way to tweak the parameters of my Synaptics pad.
I started down the road of creating a basic xorg.conf but it seems I have to have quite a lot in there in order for X to even start. I don't want to do this if I don't have to. So I have 2 questions:
- Synaptics parameters are really *user* preferences --
where should these be stored, if X isn't controlling it?
- If I do revive my old xorg.conf, am I giving up any of
the dynamic-ness of newer Xorg in F10 by doing so? I want to have X completely manage my displays itself; no static data.
Any help is appreciated! Original thread is on the forum, if you're interested (but it's a dead end, as explained in my last post).
http://forums.fedoraforum.org/showthread.php?t=200840
-Chris
--
Chris,
I forwarded this message to fedora-test-list, you are more likely to get a response over here, in contrast the regular list will complain that you posted this :(
Regards,
Antonio
On 2008-10-07, 22:26 GMT, Antonio Olivares wrote:
F10 doesn't ship with an xorg.conf and it seems that the input hotplug facility now handles all of this. However, I can't find any way to tweak the parameters of my Synaptics pad.
Read the mother of all Synaptics bugs https://bugzilla.redhat.com/show_bug.cgi?id=439386 (especially around comment 87).
Matěj
On Wed, 08 Oct 2008 18:34:38 +0200 Matej Cepl mcepl@redhat.com wrote:
Read the mother of all Synaptics bugs https://bugzilla.redhat.com/show_bug.cgi?id=439386 (especially around comment 87).
So, X has achieved the holy grail of no config file by moving all the config files to a far more obscure place and changing them to undocumented xml gibberish?
I swear there are the makings out there of an abnormal psychology text titled "The Mind of the Linux Developer" :-). [Good lord! People are finding solutions to their problems by doing simple google searches! Quick, we must change everything so all the google hits will be out of date! BU-WA-HA-HA-HA-HA!!!]
Is this the same sort of thing I'll need to do to officially configure draglock on my trackball using evdev? Right now, I disable evdev in the xorg.conf file and use the old input section to do it (because I was able to discover how to do that).
On 2008-10-08, 22:27 GMT, Tom Horsley wrote:
So, X has achieved the holy grail of no config file by moving all the config files to a far more obscure place and changing them to undocumented xml gibberish?
No, the point of this should be that computer will automagically recognize which device you have and take from the database of configurations (and take a look at /usr/share/hal/fdi/policy for illustration should look like) exact tweaks which should be done to make your device work.
Matěj
On Thu, Oct 09, 2008 at 05:25:34PM +0200, Matej Cepl wrote:
On 2008-10-08, 22:27 GMT, Tom Horsley wrote:
So, X has achieved the holy grail of no config file by moving all the config files to a far more obscure place and changing them to undocumented xml gibberish?
No, the point of this should be that computer will automagically recognize which device you have and take from the database of configurations
There is a small fly in this ointment. The above may work, usually, but very far from always. For example, if monitor EDID data are faulty or not present at all, and this is _not_ a hypothetical situation, then a configuration you are getting is busted. Also something which is possible, and even "correct" in some sense, does not need to be optimal/desired in a given situation.
It sounds like another of those "90% solutions" which happen to work, more or less, for a developer in her/his particular configuration and which are screwing you often enough.
(and take a look at /usr/share/hal/fdi/policy for illustration should look like)
Yes, I had do that on various occasions. It is never clear what to do with this dreaded XML maze or if what you are trying to hack even has a chance of working. Shudder!
Michal
On Thu, 2008-10-09 at 12:33 -0600, Michal Jaegermann wrote:
There is a small fly in this ointment. The above may work, usually, but very far from always. For example, if monitor EDID data are faulty or not present at all, and this is _not_ a hypothetical situation, then a configuration you are getting is busted. Also something which is possible, and even "correct" in some sense, does not need to be optimal/desired in a given situation.
Perfect is the enemy of good.
Ajax has in the past asked for /anybody/ to provide him situations where the EDID is bogus.
On Thu, Oct 09, 2008 at 11:36:33AM -0700, Jesse Keating wrote:
On Thu, 2008-10-09 at 12:33 -0600, Michal Jaegermann wrote:
There is a small fly in this ointment. The above may work, usually, but very far from always.
Perfect is the enemy of good.
That is precisely the point. We are seeing attempts to replace "good" situations, where imperfections can be smoothed out by a user by changing configurations when needed, but something which pretends to be "perfect" and leaves you high and dry often enough.
Ajax has in the past asked for /anybody/ to provide him situations where the EDID is bogus.
Oh, for example see https://bugzilla.redhat.com/attachment.cgi?id=315320 attached to bug 460571.
Are you seriously suggesting that a group participating in fedora-testing list will see an every piece of a misbehaving hardware and will see every possible configuration? Most of affected users will not bother at all before dismissing affected software as junk.
Michal
On Thu, 2008-10-09 at 12:52 -0600, Michal Jaegermann wrote:
Are you seriously suggesting that a group participating in fedora-testing list will see an every piece of a misbehaving hardware and will see every possible configuration? Most of affected users will not bother at all before dismissing affected software as junk.
That's what's laughable. If it fails for them now, it would have even more chance at failing for them before. If they simple see a failure, give up and move along, well we haven't really made a difference there.
Only now we have much much better capability at taking a session and running it on a variety of hardware without ever having to fiddle with a config file, because it all just works. Think Live images. Think appliance images. Think stateless. Autoconfiguration is a very very good thing, and we're in a better place with it.
On Thu, Oct 9, 2008 at 3:06 PM, Jesse Keating jkeating@redhat.com wrote:
Only now we have much much better capability at taking a session and running it on a variety of hardware without ever having to fiddle with a config file, because it all just works. Think Live images. Think appliance images. Think stateless. Autoconfiguration is a very very good thing, and we're in a better place with it.
Fair enough. But also think about an existing user base that relies on his/her system day after day. If it's messed with ......
jerry
On Thu, Oct 09, 2008 at 01:06:34PM -0700, Jesse Keating wrote:
Only now we have much much better capability at taking a session and running it on a variety of hardware without ever having to fiddle with a config file, because it all just works.
In other words you are saying: "If something does not work then this is your fault and screw you"? That is nice to know. The problem is that your perfect "all just works" simply does not - at least often enough.
Autoconfiguration is a very very good thing, and we're in a better place with it.
You are mixing two things. Autoconfiguration and an ability to easily override that autoconfiguration when it does not work or when you have good reasons not to like results. Take as an example the current anaconda with a network install. Unfortunately you are not the only one so confused.
Michal
On Thu, 2008-10-09 at 15:08 -0600, Michal Jaegermann wrote:
In other words you are saying: "If something does not work then this is your fault and screw you"? That is nice to know. The problem is that your perfect "all just works" simply does not - at least often enough.
Now, where in my statements did you get a "screw you"? If it doesn't work, we want to know about it, so that we can create the proper quirk so that instead of it just working on your system / install, it'll work on everybody's that has your setup.
Autoconfiguration is a very very good thing, and we're in a better place with it.
You are mixing two things. Autoconfiguration and an ability to easily override that autoconfiguration when it does not work or when you have good reasons not to like results. Take as an example the current anaconda with a network install. Unfortunately you are not the only one so confused.
I think you are confused too. You can still create an xorg.conf file and populate it to your heart's content. It'll get used instead of autoconfiguration.
On Thu, Oct 09, 2008 at 03:13:45PM -0700, Jesse Keating wrote:
I think you are confused too. You can still create an xorg.conf file and populate it to your heart's content.
This I happen to know. Please tell that to somebody who installs F10 for the first time and runs into troubles with a display or a Synaptics configuration.
There were indeed times when I was writing XF86Config files mostly "by hand" or with a help of tools which were helping only a tiny bit. I believe that this was a major turn off for a lot of people. It appears that if I have troubles with what was autoconfigured then I am back to that time again.
I am also worried what will happen in the future although that this particular file will stop beeing recognized does not seem to be likely (with X not really tied up to Gnome). That this general trend is what gets me worried.
Michal
On Thu, 2008-10-09 at 17:08 -0600, Michal Jaegermann wrote:
This I happen to know. Please tell that to somebody who installs F10 for the first time and runs into troubles with a display or a Synaptics configuration.
There were indeed times when I was writing XF86Config files mostly "by hand" or with a help of tools which were helping only a tiny bit. I believe that this was a major turn off for a lot of people. It appears that if I have troubles with what was autoconfigured then I am back to that time again.
I am also worried what will happen in the future although that this particular file will stop beeing recognized does not seem to be likely (with X not really tied up to Gnome). That this general trend is what gets me worried.
You happen to pick on one of the worst drivers out there, synaptics. These wouldn't work for configuration without fiddling with a config file in the first place, because of it's crappy ass configuration system relying on insecure methods.
In the future, where the norm is no X config, crap like this wouldn't be accepted and wouldn't be here to deal with.
So yeah, we've got few wrinkles to work out, and some cruft leftover from the past to clean up, but that's not bad.
On Thu, Oct 09, 2008 at 04:15:26PM -0700, Jesse Keating wrote:
You happen to pick on one of the worst drivers out there, synaptics.
Again! The problem is that this imaginary "perfect configuration system" where everything is autoconfigured tends to blissfully ignore all that crappy hardware, or special requirements, which are out there. Even if they are minority they are real. And this is not a question of X. For example, NetworkManager works really well in some situations and badly messes out in others. This was like that from the very beginning, for quite a while now, and various bug reports were filed. And???
Michal
On Thu, 2008-10-09 at 17:46 -0600, Michal Jaegermann wrote:
Again! The problem is that this imaginary "perfect configuration system" where everything is autoconfigured tends to blissfully ignore all that crappy hardware, or special requirements, which are out there. Even if they are minority they are real. And this is not a question of X. For example, NetworkManager works really well in some situations and badly messes out in others. This was like that from the very beginning, for quite a while now, and various bug reports were filed. And???
And it's being improved, more and more with every release. And when it doesn't work, the network service is there to fill that gap. But without having NM there for everybody as a default, we wouldn't get the exposure we need to find the corner cases to fix. We are Fedora, we release early, we release often, and we improve along the way.
It's funny that you pick NetworkManager, because the last 15 or so people that have used Fedora from another OS for the first time, NM is one of the things they constantly tell me about as being fantastic, and the first thing they notice that is better than the alternatives. NM drives users to us, and keeps them here. If we didn't have it, we'd lose on these users. NM is vastly better than what we had before. Is it perfect? No. Is it improving, yes. Is it worth the speedbumps along the way? Absolutely.
On Thu, Oct 09, 2008 at 04:52:47PM -0700, Jesse Keating wrote:
It's funny that you pick NetworkManager, because the last 15 or so people that have used Fedora from another OS for the first time, NM is one of the things they constantly tell me about as being fantastic,
No, it is not funny at all and I did that on purpose. Because NM is really good _when_ it works correctly. The problem is those situations when it does not work but and the general approach looks like "most everybody is happy and down with malcontents".
Michal
On 2008-10-10, 00:09 GMT, Michal Jaegermann wrote:
No, it is not funny at all and I did that on purpose. Because NM is really good _when_ it works correctly. The problem is those situations when it does not work but and the general approach looks like "most everybody is happy and down with malcontents".
No, it is not general approach -- these are bugs and are they fixed all the time.
Matej
Once upon a time, Jesse Keating jkeating@redhat.com said:
In the future, where the norm is no X config, crap like this wouldn't be accepted and wouldn't be here to deal with.
For some unknown reason, X thinks my 24" monitor is the size of a postcard when connected via DVI or HDMI, so I have to edit xorg.conf or I get huge fonts.
Quoting Chris Adams cmadams@hiwaay.net:
Once upon a time, Jesse Keating jkeating@redhat.com said:
In the future, where the norm is no X config, crap like this wouldn't be accepted and wouldn't be here to deal with.
For some unknown reason, X thinks my 24" monitor is the size of a postcard when connected via DVI or HDMI, so I have to edit xorg.conf or I get huge fonts.
i had that very problem today with a samsung syncmaster 245T flat panel. hooked it up to my WUXGA laptop via DVI, and was rewarded with my poor laptop being driven to a video setting involving *massive* font size, apparently due to totally stupid EDID info being supplied by the monitor (which claimed to be able to handle 1920x540 or 640x480).
that was thoroughly annoying, and i blame samsung for releasing a $600 WUXGA display on the world that is so hopelessly misconfigured.
rday
Once upon a time, Robert P. J. Day rpjday@crashcourse.ca said:
that was thoroughly annoying, and i blame samsung for releasing a $600 WUXGA display on the world that is so hopelessly misconfigured.
When I hook up via VGA, I get the right screen size. Windows also somehow seemed to figure it out without a problem.
On 2008-10-10, 00:38 GMT, Robert P. J. Day wrote:
i had that very problem today with a samsung syncmaster 245T flat panel. hooked it up to my WUXGA laptop via DVI, and was rewarded with my poor laptop being driven to a video setting involving *massive* font size, apparently due to totally stupid EDID info being supplied by the monitor (which claimed to be able to handle 1920x540 or 640x480).
that was thoroughly annoying, and i blame samsung for releasing a $600 WUXGA display on the world that is so hopelessly misconfigured.
File a bug, please (and attach working /etc/X11/xorg.conf if you have one, and certainly whatever /var/log/Xorg.*.log and /var/log/dmesg you have).
Matej
On 2008-10-10, 00:34 GMT, Chris Adams wrote:
For some unknown reason, X thinks my 24" monitor is the size of a postcard when connected via DVI or HDMI, so I have to edit xorg.conf or I get huge fonts.
And number of the bug in bugzilla.redhat.com is?
Matej
Once upon a time, Matej Cepl mcepl@redhat.com said:
On 2008-10-10, 00:34 GMT, Chris Adams wrote:
For some unknown reason, X thinks my 24" monitor is the size of a postcard when connected via DVI or HDMI, so I have to edit xorg.conf or I get huge fonts.
And number of the bug in bugzilla.redhat.com is?
Filed in August:
https://bugzilla.redhat.com/show_bug.cgi?id=458747
On 2008-10-09, 21:08 GMT, Michal Jaegermann wrote:
In other words you are saying: "If something does not work then this is your fault and screw you"? That is nice to know.
No, he isn't (or at least I am not) -- the world where we are coming from is not that bright either. The only difference between now and (near) future is that now still people google for the small lines of text to put into /etc/X11/xorg.conf to make work their particular piece of turd. In the future hopefully all these tidbits of information could be collected, packaged, and served with the Xorg so that people wouldn't have to apply it themselves (or even know, that some hints are used).
See for example for what goes to /usr/share/hal* on http://people.freedesktop.org/~hughsient/quirk/ -- I would love to see some database of quirks which would make Xorg work without anybody even noticing.
You are mixing two things. Autoconfiguration and an ability to easily override that autoconfiguration when it does not work or when you have good reasons not to like results. Take as an example the current anaconda with a network install. Unfortunately you are not the only one so confused.
I don't want to comment on the NetworkManager -- works pretty decently for me (certainly much better than whatever else I used in the past) -- but I want to emphasize a small fact that /etc/hal/fdi/ is and /etc subdirectory, so you (or anybody else) can have their specific configuration there.
Also if you have such problems to write a line of code to XML file, then probably you shouldn't try.
Best,
Matěj
On Fri, Oct 10, 2008 at 12:23:40AM +0200, Matej Cepl wrote:
On 2008-10-09, 21:08 GMT, Michal Jaegermann wrote:
In other words you are saying: "If something does not work then this is your fault and screw you"? That is nice to know.
No, he isn't (or at least I am not) -- the world where we are coming from is not that bright either. The only difference between now and (near) future is that now still people google for the small lines of text to put into /etc/X11/xorg.conf to make work their particular piece of turd. In the future hopefully all these tidbits of information could be collected, packaged, and served with the Xorg so that people wouldn't have to apply it themselves (or even know, that some hints are used).
I think that a great deal of the trouble is (and I fear I don't have a good solution) the lack of notification of such changes. For example, FreeBSD tries to operate on the POLA system, Principle Of Least Astonishment. When major changes take place, there is a HEADSUP to the mailing list, as well as their /usr/src/UPDATING for system changes and /usr/ports/UPDATING for 3rd party program changes.
I don't think that's practical with Fedora because of its very nature as, more or less, a test bed. However, things that are relatively drastic changes, such as a removal of xorg.conf, could probably be better announced.
Things like the Anaconda issue seem more of a bug. I haven't been following that one closely, but I was under the impression that it's going to be fixed quickly.
Just a small example--at some point or another, rather than being able to type linux <whatever> at installation, that option was gone. People had to google to find out the new way to reach the boot prompt. Something like that, which would affect a lot of people, could have probably been more widely announced and documented.
We, the users, really do, (though we often complain) appreciate the work you developers do for us, though we get upset when things break. On the other hand, I think most of us realize that with Fedora, especiall with Rawhide, things will break.
What would be great, I think, though I have no idea if it is at all feasible, would be with things like this, to have a line of text appear perhaps, saying, there is no longer a default xorg--if this doesn't work for you, please file a bug with your hardware information. blah blah. Also please note that you can construct an xorg with xorconfig (if that's still available, I haven't checked--I have been fortunate enough so that I didn't even realize it had been removed.)
I think that a lot of the anger users sometimes feel is because these things take them by surprise. Yes, there are lists of changes--they aren't always complete, and I suspect many of us just skim through them anyway. However, major changes could perhaps, merit a headsup.
I do want to reiterate that we users really do appreciate the efforts the developers make on our behalf.
On 2008-10-09, 23:13 GMT, Scott Robbins wrote:
I don't think that's practical with Fedora because of its very nature as, more or less, a test bed. However, things that are
^^^^^^^^^^^ I would prefer to characterize Fedora as a developer's distribution of choice, but whatever.
relatively drastic changes, such as a removal of xorg.conf, could probably be better announced.
Note, that xorg.conf was never deprecated (meaning, that you can still use it and it is read by Xorg on start) and it was not mandatory since Fedora Core 6 (at least since then it was considered a bug, when you didn't get functional X when xorg.conf was removed). I don't think we are that hasty.
What would be great, I think, though I have no idea if it is at all feasible, would be with things like this, to have a line of text appear perhaps, saying, there is no longer a default xorg--if this doesn't work for you, please file a bug with your hardware information.
That's called Release Notes and if we ever remove xorg.conf from Fedora, be sure you will be able to read about it there (and in many other places). But I don't think that such drastic change will happen anytime soon.
Also please note that you can construct an xorg with xorconfig (if that's still available, I haven't checked--I have been fortunate enough so that I didn't even realize it had been removed.)
Yes, and there is still system-config-display.
I think that a lot of the anger users sometimes feel is because these things take them by surprise. Yes, there are lists of changes--they aren't always complete, and I suspect many of us just skim through them anyway. However, major changes could perhaps, merit a headsup.
BTW, there is no class of "you developers" distinct from "us users" in the Fedoraland. If you want to help with Release Notes, there is a huge need of help with writing them, especially from people who are not developers. Take a look at https://fedoraproject.org/wiki/DocsProject/Join, pick some Beat, and then just hang around particular group of developers (their email list, etc.) and write about that.
Best,
Matej Cepl
Matej Cepl wrote:
What would be great, I think, though I have no idea if it is at all feasible, would be with things like this, to have a line of text appear perhaps, saying, there is no longer a default xorg--if this doesn't work for you, please file a bug with your hardware information.
That's called Release Notes and if we ever remove xorg.conf from Fedora, be sure you will be able to read about it there (and in many other places). But I don't think that such drastic change will happen anytime soon.
Nobody reads the release notes It is time that a certain people or group of people start to realize that.
A good pointer to that is that nobody complained when team anaconda removed the release notes in anaconda.
We have to find a better way to get the info ( or least the major ones ) to our users.
Floor is open for suggestions..
Keep ideas aimed at people that have no network connection as in this was a hand out cd/dvd usb key.
Also please note that you can construct an xorg with xorconfig (if that's still available, I haven't checked--I have been fortunate enough so that I didn't even realize it had been removed.)
Yes, and there is still system-config-display.
Note in F10 system-config-display will not get installed by default so you will need to install it before using it.
JBG
Jóhann B. Guðmundsson wrote:
Nobody reads the release notes It is time that a certain people or group of people start to realize that.
A good pointer to that is that nobody complained when team anaconda removed the release notes in anaconda.
We have to find a better way to get the info ( or least the major ones ) to our users.
Floor is open for suggestions..
If nobody reads the release notes, nobody can force them to read anything else either. Fact is, that some people read it and others don't. Feel free to educate them. We have been linking to the release notes from the front page of the website for a long time now.
Rahul
On 2008-10-10, 13:45 GMT, Rahul Sundaram wrote:
If nobody reads the release notes, nobody can force them to read anything else either. Fact is, that some people read it and others don't. Feel free to educate them. We have been linking to the release notes from the front page of the website for a long time now.
Well, the truth is, I don't remember whether we have them still available in Anaconda -- are they there?
Matej
Matej Cepl wrote:
On 2008-10-10, 13:45 GMT, Rahul Sundaram wrote:
If nobody reads the release notes, nobody can force them to read anything else either. Fact is, that some people read it and others don't. Feel free to educate them. We have been linking to the release notes from the front page of the website for a long time now.
Well, the truth is, I don't remember whether we have them still available in Anaconda -- are they there?
Nope. Not anymore.
Rahul
Jóhann B. Guðmundsson wrote:
Nobody reads the release notes It is time that a certain people or group of people start to realize that.
A good pointer to that is that nobody complained when team anaconda removed the release notes in anaconda.
We have to find a better way to get the info ( or least the major ones ) to our users.
Floor is open for suggestions..
If nobody reads the release notes, nobody can force them to read anything else either. Fact is, that some people read it and others don't. Feel free to educate them. We have been linking to the release notes from the front page of the website for a long time now.
Rahul
Rahul Sundaram wrote:
Jóhann B. Guðmundsson wrote:
Nobody reads the release notes It is time that a certain people or group of people start to realize that.
A good pointer to that is that nobody complained when team anaconda removed the release notes in anaconda.
We have to find a better way to get the info ( or least the major ones ) to our users.
Floor is open for suggestions..
If nobody reads the release notes, nobody can force them to read anything else either. Fact is, that some people read it and others don't. Feel free to educate them. We have been linking to the release notes from the front page of the website for a long time now.
Rahul
I'm feeling free of educating you.
Congrats on the smart way of having a link to the release notes from the front page of the website.
Now think of all the handouts of Fedora dvds cd's usb's and conferences etc.
Do we handout release notes... NO WE DON'T!
Does the default startup page in the browser point to the Fedora release notes page for those end users that might have internet connection.
NO IT'S DOES NOT"!
But we have a tiny link to the release notes below the search engine <*sight*>
It has been going on for to long that major/drastic changes have been buried in the "Release notes"
We have to find a better way of getting the info to our end users.
JBG
Jóhann B. Guðmundsson wrote:
Now think of all the handouts of Fedora dvds cd's usb's and conferences etc.
Do we handout release notes... NO WE DON'T!
It is part of the fedora release notes package in the distribution. Part of the default bookmarks as well.
Does the default startup page in the browser point to the Fedora release notes page for those end users that might have internet connection.
NO IT'S DOES NOT"!
We did before and it didn't make much of a difference.
We have to find a better way of getting the info to our end users.
If you have bright ideas, let us know.
Rahul
Rahul Sundaram wrote:
Jóhann B. Guðmundsson wrote:
Now think of all the handouts of Fedora dvds cd's usb's and conferences etc.
Do we handout release notes... NO WE DON'T!
It is part of the fedora release notes package in the distribution. Part of the default bookmarks as well.
Does the default startup page in the browser point to the Fedora release notes page for those end users that might have internet connection.
NO IT'S DOES NOT"!
We did before and it didn't make much of a difference.
Well if that does not further proofing my point....
We have to find a better way of getting the info to our end users.
If you have bright ideas, let us know.
I'm curious what your definition of "us" is so please elaborate who you consider "us"
I've already had discussion with individuals that would be involved in implementing my ideas but to no prevail and these where all ideas on trying to get the release notes more visible to the end user
The answers I got was..
Adds to much workload, as in code and maintaining that code followed by "nobody reads those release notes anyway so it's not worth the trouble" Which is true and valid point so there's no use wasting time and money on it. ( Yet vital things still are put in the release notes followed by the excuse the user should have read the release notes )
Which means we need to come up with an alternative solution.
"Floor is open for suggestions"
So far I've not heard any idea from you.
Jóhann B. Guðmundsson wrote:
If you have bright ideas, let us know.
I'm curious what your definition of "us" is so please elaborate who you consider "us"
Those of us who write the release notes including the documentation team.
I've already had discussion with individuals that would be involved in implementing my ideas but to no prevail and these where all ideas on trying to get the release notes more visible to the end user
The answers I got was..
Adds to much workload, as in code and maintaining that code followed by "nobody reads those release notes anyway so it's not worth the trouble" Which is true and valid point so there's no use wasting time and money on it. ( Yet vital things still are put in the release notes followed by the excuse the user should have read the release notes )
Requests for enhancements should go into http://bugzilla.redhat.com. Did they?
Which means we need to come up with an alternative solution.
"Floor is open for suggestions"
So far I've not heard any idea from you.
I am not the one complaining.
Rahul
Rahul Sundaram wrote:
Jóhann B. Guðmundsson wrote:
If you have bright ideas, let us know.
I'm curious what your definition of "us" is so please elaborate who you consider "us"
Those of us who write the release notes including the documentation team.
I've already had discussion with individuals that would be involved in implementing my ideas but to no prevail and these where all ideas on trying to get the release notes more visible to the end user
The answers I got was..
Adds to much workload, as in code and maintaining that code followed by "nobody reads those release notes anyway so it's not worth the trouble" Which is true and valid point so there's no use wasting time and money on it. ( Yet vital things still are put in the release notes followed by the excuse the user should have read the release notes )
Requests for enhancements should go into http://bugzilla.redhat.com. Did they?
Yes they did now go look.
Which means we need to come up with an alternative solution.
"Floor is open for suggestions"
So far I've not heard any idea from you.
I am not the one complaining.
Rahul
Oh so it's a complaint now pointing out things that might go better and ask people to come up with suggestion.
Jóhann B. Guðmundsson wrote:
Rahul Sundaram wrote:
Requests for enhancements should go into http://bugzilla.redhat.com. Did they?
Yes they did now go look.
If you want them discussed, you should be listing them directly. It provides additional context.
Oh so it's a complaint now pointing out things that might go better and ask people to come up with suggestion.
Sure, you can do that but don't expect me specifically to solve the problem of people refusing to read important information. I simply don't see a solution to that.
Rahul
On Fri, Oct 10, 2008 at 9:57 AM, Rahul Sundaram sundaram@fedoraproject.org wrote:
I am not the one complaining.
And the people who are complaining deserve better than that. That kind of response shows you also haven't been listening.
jerry
Jerry Amundson wrote:
On Fri, Oct 10, 2008 at 9:57 AM, Rahul Sundaram wrote:
I am not the one complaining.
And the people who are complaining deserve better than that. That kind of response shows you also haven't been listening.
Sure, I have. I honestly don't see a solution.
Rahul
On Fri, Oct 10, 2008 at 10:14 AM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Jerry Amundson wrote:
On Fri, Oct 10, 2008 at 9:57 AM, Rahul Sundaram wrote:
I am not the one complaining.
And the people who are complaining deserve better than that. That kind of response shows you also haven't been listening.
Sure, I have. I honestly don't see a solution.
And I think that's the lesson in all this. Different groups have implemented solutions, for a problem that was never really well defined in the first place, and now the end user suffers the consequences. This, on "a developer's distribution of choice"?
jerry
Jerry Amundson wrote:
On Fri, Oct 10, 2008 at 10:14 AM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Jerry Amundson wrote:
On Fri, Oct 10, 2008 at 9:57 AM, Rahul Sundaram wrote:
I am not the one complaining.
And the people who are complaining deserve better than that. That kind of response shows you also haven't been listening.
Sure, I have. I honestly don't see a solution.
And I think that's the lesson in all this. Different groups have implemented solutions, for a problem that was never really well defined in the first place, and now the end user suffers the consequences. This, on "a developer's distribution of choice"?
I am not sure what you are referring to. If you want to help, this is a good chance to define what is the problem and write out a list of solutions. Let's start with this basic assumption: You will never get everyone to read the release notes and other important information. Some end users will continue blindly install or upgrade their operating system no matter what.
Rahul
On Fri, Oct 10, 2008 at 10:27 AM, Rahul Sundaram sundaram@fedoraproject.org wrote:
I am not sure what you are referring to. If you want to help, this is a good chance to define what is the problem and write out a list of solutions. Let's start with this basic assumption: You will never get everyone to read the release notes and other important information. Some end users will continue blindly install or upgrade their operating system no matter what.
A thread with 51 messages in it, (some of them teetering on emotional :-) and you ask me "to define what is the problem and write out a list of solutions"?
I'll think about it - while I spend a few hours calming down doing my day job. :-)
jerry
Jerry Amundson wrote:
On Fri, Oct 10, 2008 at 10:27 AM, Rahul Sundaram sundaram@fedoraproject.org wrote:
I am not sure what you are referring to. If you want to help, this is a good chance to define what is the problem and write out a list of solutions. Let's start with this basic assumption: You will never get everyone to read the release notes and other important information. Some end users will continue blindly install or upgrade their operating system no matter what.
A thread with 51 messages in it, (some of them teetering on emotional :-) and you ask me "to define what is the problem and write out a list of solutions"?
Yes because multiple problems are being mixed together. If we want to solve any of them, we need a more organized effort.
Rahul
On Fri, 2008-10-10 at 14:10 +0000, "Jóhann B. Guðmundsson" wrote:
Do we handout release notes... NO WE DON'T!
Well maybe you should.
Jesse Keating wrote:
On Fri, 2008-10-10 at 14:10 +0000, "Jóhann B. Guðmundsson" wrote:
Do we handout release notes... NO WE DON'T!
Well maybe you should.
Well Jesse I'll take you on that offer the fedoraproject shall pay and print out equal amount of release notes as a cd's, dvd' or usb it's going to handout pay for my trip at each event it will be distributing the cd's dvd's or the usb keys and I will personally stand there during the distribution of the cd's dvd's or usb key's and hand out the release notes along with the Fedora.
JBG.
2008/10/10 "Jóhann B. Guðmundsson" johannbg@hi.is:
Well Jesse I'll take you on that offer the fedoraproject shall pay and print out equal amount of release notes as a cd's, dvd' or usb it's going to handout pay for my trip at each event it will be distributing the cd's dvd's or the usb keys and I will personally stand there during the distribution of the cd's dvd's or usb key's and hand out the release notes along with the Fedora.
Not that Fedora actually distributes a lot of media directly, but printing up release notes like this seems rather environmentally unfriendly. Just printing and distributing the release notes with the media doesn't mean that people are going to read them.
On Fri, 2008-10-10 at 17:05 +0000, "Jóhann B. Guðmundsson" wrote:
Well Jesse I'll take you on that offer the fedoraproject shall pay and print out equal amount of release notes as a cd's, dvd' or usb it's going to handout pay for my trip at each event it will be distributing the cd's dvd's or the usb keys and I will personally stand there during the distribution of the cd's dvd's or usb key's and hand out the release notes along with the Fedora.
Or you can point out as you hand out the CDs that there are release notes to be read, or if you're handing out a USB key, if there is space you can put a copy of the release notes on the USB itself, outside the live image, so that one can plug in the USB and read the release notes without booting to the Live image.
Jóhann B. Guðmundsson wrote, On 10/10/2008 09:41 AM:
Matej Cepl wrote:
What would be great, I think, though I have no idea if it is at all feasible, would be with things like this, to have a line of text appear perhaps, saying, there is no longer a default xorg--if this doesn't work for you, please file a bug with your hardware information.
That's called Release Notes and if we ever remove xorg.conf from Fedora, be sure you will be able to read about it there (and in many other places). But I don't think that such drastic change will happen anytime soon.
Nobody reads the release notes It is time that a certain people or group of people start to realize that.
A good pointer to that is that nobody complained when team anaconda removed the release notes in anaconda.
We have to find a better way to get the info ( or least the major ones ) to our users.
Floor is open for suggestions..
Keep ideas aimed at people that have no network connection as in this was a hand out cd/dvd usb key.
And even in Anaconda, IIRC, you did not see it until you were pretty much into the install phase.
being able to say have a 'just release notes' and\or 'just MAJOR changes from last F' options from the grub/syslinux menus on the CD could be interesting. Those could be chosen with out the fear of pushing a wrong button and wiping out your working system before you really are ready.
Also please note that you can construct an xorg with xorconfig (if that's still available, I haven't checked--I have been fortunate enough so that I didn't even realize it had been removed.)
Yes, and there is still system-config-display.
Note in F10 system-config-display will not get installed by default so you will need to install it before using it.
Maybe I did not understand some of the things in the xorg.log I was seeing in the recent (12 months) past, but it would be nice to have two options with the current Xorg config system: 1) kick out a xorg.conf file based on the detected working settings, i.e, what X is going to use without a conf file there. 2) kick out a xorg.conf file based on ALL the detected capabilities, i.e, if the video card can use a particular modeline but the monitor does not CLAIM to support it, then still put the modeline in the conf file, and the other way around, if monitor supports a resolution/scanrate/whatever that the card does not, then still put it in the conf file, so that if the user THINKS they know better, then they can select something that is supported instead of trying to dis-cypher the data from the xorg.log file. Of course this conf file should be marked top bottom and middle with things indicating 'please put a bug in an appropriate zilla, and be careful with what you do here because something indicated that the components of your system did not have full matches on everything.'
So if those were put into an fedora X bug do you think they would get anything but a NOTABUGWONTFIX ?
On 2008-10-10, 13:41 GMT, Jóhann B. Guðmundsson wrote:
Nobody reads the release notes
First you asked for some reading and now you don't want to read it? Don't understand. If they don't read them, tough luck, I guess.
We have to find a better way to get the info ( or least the major ones ) to our users.
There used to be (or still is? I am not sure) a button with Release Notes somewhere in the beginning of Anaconda. I like that.
Matej
On Fri, Oct 10, 2008 at 02:58:03PM +0200, Matej Cepl wrote:
Note, that xorg.conf was never deprecated (meaning, that you can still use it and it is read by Xorg on start)
X is an "outside" project and preventing that would likely require essential code changes so I do not really expect that this will happen. It may turn out that writing a new xorg.conf will be a "hacker's delight" again but that is another story.
Only I think that with a focus solely on xorg.conf you are loosing a bigger picture.
Here is another example from the last few days (or small weeks). In '/usr/bin/gnome-wm' you now will find the following comment:
# # NOTE: DON'T USE THIS. Please have your window manager install # a desktop file and change the gconf key # /desktop/gnome/session/required_components/windowmanager
Guess what? It really does not work. This was '/apps/gnome-session/rh/window_manager' working key yet very recently and just resetting that another gconf key simply does not have any effect. True, the comment says something about "a desktop file" too so I tried to provide something similar to metacity-wm.desktop. The best result I got so far was no window manager at all. Maybe what is truly expected is documented somewhere, and who knows where, and maybe not. Do you feel lucky? Do not tell me that anybody hardly noticed. This is not the point.
Or maybe you can try to find a reasonable way to disable suspend/hibernate on some machine in such way that this cannot be turned on even by an accident and it survive updates? If not then something in fdi policies which worked yesterday but today is not valid anymore and you cannot even start guessing why. Some gdm adjustments for a change? Try to fill a bugzilla report and it will be ignored or closed with NOTABUG.
It is not a particular individual instance of something but such lists can go on and on and on and after a while you really feel forced into a maze of hacking "obscure configurations" like said in a message which opened this thread.
Michal
On Fri, Oct 10, 2008 at 02:58:03PM +0200, Matej Cepl wrote:
On 2008-10-09, 23:13 GMT, Scott Robbins wrote:
I don't think that's practical with Fedora because of its very nature as, more or less, a test bed. However, things that are
^^^^^^^^^^^I would prefer to characterize Fedora as a developer's distribution of choice, but whatever.
Fair enough. There were a lot of replies to this, let me try to do an overly brief summation.
PROBLEM: Often, major changes are only documented in the release notes, which most people don't read. My feeling on this is that this is because the release notes are quite complete, and major changes may be easily overlooked. Some feel that if the users won't read the release notes, then it's on their own head. Others feel there should be a better way.
I can think of two examples of how others have dealt with the issue. One example is Ubuntu. For example, when they brought pulse-audio into their alpha or beta, the Hardy one, I think, they had an easy to find thing on their front page, mentioning it. They also mentioned NOTE--this may break sound if you don't use Gnome.
One problem with this one is that Fedora is a developer's distribution in many ways. :) (Or a testbed) <ducks>.
However, FreeBSD, while having very complete release notes also deals with major possible surprises by having an UPDATING section. When one downloads the latest source code, they will look at /usr/src/UPDATING, which will usually (of course, it's not perfect) mention changes and possible solutions for issues that will affect most users.
Does this seem feasible? For example, things like no more default xorg.conf (even if it's not deprecated). Other things that spring to mind are things like tying sound to ConsoleKit which broke sound for many people.
Basically, the major changes that may affect many users, especially when they don't use Gnome. Many times, as a fluxbox user, I've come across things that seem to almost be a Just Me (TM) issue, that work properly if I use Gnome.
So, that's my suggestion. Include an UPDATING that gets updated when various changes that might surprise people are made. What might surprise people is of course, subjective, but....
Scott Robbins wrote:
So, that's my suggestion. Include an UPDATING that gets updated when various changes that might surprise people are made. What might surprise people is of course, subjective, but....
Why do you think that a complete new file like this would be read by more people than the better known release notes which already has a section specific to upgrades?
Rahul
On Sat, Oct 11, 2008 at 03:31:58AM +0530, Rahul Sundaram wrote:
Scott Robbins wrote:
So, that's my suggestion. Include an UPDATING that gets updated when various changes that might surprise people are made. What might surprise people is of course, subjective, but....
Why do you think that a complete new file like this would be read by more people than the better known release notes which already has a section specific to upgrades?
I guess it's a habit from FreeBSD. Everyone knew that it should be read before updating. (FreeBSD has a more distinct separation between system and 3rd party programs as well, so there is also a /usr/ports/UPDATING.)
Also, I think that if it were publicized, for example, if something is mentioned there, and then someone posts, for example, on Fedora forums about it, someone else will post back, Didn't you read UPDATING?
Lastly, the idea (again it's certainly easier said than done) is that this would cover major, perhaps system breaking changes. For example, to make one up...
Changelog
programX updated 2.1.1.2 programY updated 2.1.1.4 Majorchange in NetworkManager--if you don't follow steps X, Y, and Z it won't work).
Then in UPDATING
<date whatever> NetworkManager has been changed. You must now do X, Y, and Z before it will run properly.
So, I think that if it were done like that, and confined to major changes (again subjective--for example, for me, tying sound to ConsoleKit was major, for Gnome users it probably wasn't), people would begin to read it.
Scott Robbins wrote:
On Sat, Oct 11, 2008 at 03:31:58AM +0530, Rahul Sundaram wrote:
Scott Robbins wrote:
So, that's my suggestion. Include an UPDATING that gets updated when various changes that might surprise people are made. What might surprise people is of course, subjective, but....
Why do you think that a complete new file like this would be read by more people than the better known release notes which already has a section specific to upgrades?
I guess it's a habit from FreeBSD. Everyone knew that it should be read before updating.
Yes, but very few people have such prior knowledge and the audience for Fedora is different. A lot of people know they "should" read release notes but don't anyway or miss out changes or the impact of those changes.
Also, I think that if it were publicized, for example, if something is mentioned there, and then someone posts, for example, on Fedora forums about it, someone else will post back, Didn't you read UPDATING?
That's pretty much what we do with the release notes. A big reason why I contribute to the release notes is because I was tired of explaining the same changes to everybody trying a new release.
Also release notes is written in the wiki, converted into docbook and following the documentation team process including translations into dozens of languages. A separate text file just splinters the process.
At any rate, if you believe this is useful and willing to make it happen, feel free to post to fedora-docs list. Despite my doubts on this suggestion, if it turns to be more effective, that would be a good thing.
Rahul
On Sat, Oct 11, 2008 at 05:01:43AM +0530, Rahul Sundaram wrote:
Scott Robbins wrote:
So, that's my suggestion. Include an UPDATING that gets updated when various changes that might surprise people are made. What might surprise people is of course, subjective, but....
Why do you think that a complete new file like this would be read by more people than the better known release notes which already has a section specific to upgrades?
I guess it's a habit from FreeBSD. Everyone knew that it should be read before updating.
Yes, but very few people have such prior knowledge and the audience for Fedora is different. A lot of people know they "should" read release notes but don't anyway or miss out changes or the impact of those changes.
That's a very valid point. I was offering it as a sample suggestion. What I do, myself, is when I come across such things that affect me, is usually put up a page, which, judging from various emails I get, people do find helpful.
That's pretty much what we do with the release notes. A big reason why I contribute to the release notes is because I was tired of explaining the same changes to everybody trying a new release.
Also release notes is written in the wiki, converted into docbook and following the documentation team process including translations into dozens of languages. A separate text file just splinters the process.
Agreed. Again, it was a suggestion of a possible solution, but as you point out, the audience is quite different.
At any rate, if you believe this is useful and willing to make it happen, feel free to post to fedora-docs list. Despite my doubts on this suggestion, if it turns to be more effective, that would be a good thing.
Actually, you've more or less talked me out of it. :)
Which puts me back in the list of people who don't follow release notes as closely as I might.
It's easier, in many ways, with FreeBSD, because of the separation between 3rd party programs and the base system. For instance, anything concerning xorg is under one group, samba is another, etc. etc.
I really don't have the perfect solution--there probably isn't one, again, due to the nature of Fedora which changes so quickly.
The biggest problem for someone like you, who takes on the extremely daunting task of writing release notes, is, how to judge which are major and which are minor changes, especially when you have to write up 20 at a time.
I do think most of us realize this.
Once upon a time, Matej Cepl mcepl@redhat.com said:
I don't want to comment on the NetworkManager -- works pretty decently for me (certainly much better than whatever else I used in the past) -- but I want to emphasize a small fact that /etc/hal/fdi/ is and /etc subdirectory, so you (or anybody else) can have their specific configuration there.
There seems to be a lack of information on how to do things though. For example, when I asked about how to configure serial port ownership (to replace console.perms), I got a thread with a bunch of discussion, but I couldn't figure out a way to do it.
On Thu, Oct 09, 2008 at 11:36:33 -0700, Jesse Keating jkeating@redhat.com wrote:
On Thu, 2008-10-09 at 12:33 -0600, Michal Jaegermann wrote:
There is a small fly in this ointment. The above may work, usually, but very far from always. For example, if monitor EDID data are faulty or not present at all, and this is _not_ a hypothetical situation, then a configuration you are getting is busted. Also something which is possible, and even "correct" in some sense, does not need to be optimal/desired in a given situation.
Perfect is the enemy of good.
Ajax has in the past asked for /anybody/ to provide him situations where the EDID is bogus.
I have had a ticket open since last February where the driver ignores a monitor because it doesn't do EDID and ends up not sending any signal to the DVI port (I suspect it is getting sent to the VGA port). I have to patch xorg-x11-drv-ati everytime a new version becomes available. This actually works pretty well, but is still annoying.
On Thu, 2008-10-09 at 23:29 -0500, Bruno Wolff III wrote:
On Thu, Oct 09, 2008 at 11:36:33 -0700, Jesse Keating jkeating@redhat.com wrote:
On Thu, 2008-10-09 at 12:33 -0600, Michal Jaegermann wrote:
There is a small fly in this ointment. The above may work, usually, but very far from always. For example, if monitor EDID data are faulty or not present at all, and this is _not_ a hypothetical situation, then a configuration you are getting is busted. Also something which is possible, and even "correct" in some sense, does not need to be optimal/desired in a given situation.
Perfect is the enemy of good.
Ajax has in the past asked for /anybody/ to provide him situations where the EDID is bogus.
I have had a ticket open since last February where the driver ignores a monitor because it doesn't do EDID and ends up not sending any signal to the DVI port (I suspect it is getting sent to the VGA port). I have to patch xorg-x11-drv-ati everytime a new version becomes available. This actually works pretty well, but is still annoying.
Bug number? I drown in bugzilla.
- ajax
On Fri, Oct 10, 2008 at 10:24:58 -0400, Adam Jackson ajax@redhat.com wrote:
On Thu, 2008-10-09 at 23:29 -0500, Bruno Wolff III wrote:
I have had a ticket open since last February where the driver ignores a monitor because it doesn't do EDID and ends up not sending any signal to the DVI port (I suspect it is getting sent to the VGA port). I have to patch xorg-x11-drv-ati everytime a new version becomes available. This actually works pretty well, but is still annoying.
Bug number? I drown in bugzilla.
It's 431691. It has been looked at before, so I don't know that you'll be able to do anything more now. Plus it isn't that high of a priority for me as I have the routine of patching down to where it only takes me a couple of minutes to do updates. I'd rather have you guys finishing up the mode setting stuff in time for the release than working on that particular bug right now.
For the record to make my card work I force MT_DFP to be set for my monitor instead of MT_NONE (in a way that isn't generally appropiate). I entered the thread in response to Jesse's request about bugs filed for issues related to EDID problems.
On Fri, 2008-10-10 at 10:54 -0500, Bruno Wolff III wrote:
On Fri, Oct 10, 2008 at 10:24:58 -0400, Adam Jackson ajax@redhat.com wrote:
On Thu, 2008-10-09 at 23:29 -0500, Bruno Wolff III wrote:
I have had a ticket open since last February where the driver ignores a monitor because it doesn't do EDID and ends up not sending any signal to the DVI port (I suspect it is getting sent to the VGA port). I have to patch xorg-x11-drv-ati everytime a new version becomes available. This actually works pretty well, but is still annoying.
Bug number? I drown in bugzilla.
It's 431691. It has been looked at before, so I don't know that you'll be able to do anything more now. Plus it isn't that high of a priority for me as I have the routine of patching down to where it only takes me a couple of minutes to do updates. I'd rather have you guys finishing up the mode setting stuff in time for the release than working on that particular bug right now.
For the record to make my card work I force MT_DFP to be set for my monitor instead of MT_NONE (in a way that isn't generally appropiate). I entered the thread in response to Jesse's request about bugs filed for issues related to EDID problems.
This is actually more of a connection sense bug than an EDID bug. I'll take another look though, I'm entirely too familiar with that code these days.
One thing that we should probably do is extend gnome-display-properties to allow the user to demand modes outside what the monitor claims to be able to do. If anyone's looking for a good small project...
- ajax
On Fri, Oct 10, 2008 at 15:37:27 -0400, Adam Jackson ajax@redhat.com wrote:
This is actually more of a connection sense bug than an EDID bug. I'll take another look though, I'm entirely too familiar with that code these days.
I think that part of the driver knows there is something connected to the DVI port (especially since it used to work a while back) but because the EDID info isn't what is expected this is ignored. And what I think ends up happening is that with the driver not thinking any monitor is attached that it defaults to using the VGA port.
I tried looking at the driver source to figure out where it might be doing this based on th EDID information but couldn't grok that. So I ended mucking with what I could grok and forced the monitor type in a place where it was set to MT_NONE.
On 2008-10-09, 18:33 GMT, Michal Jaegermann wrote:
There is a small fly in this ointment. The above may work, usually, but very far from always. For example, if monitor EDID data are faulty or not present at all, and this is _not_ a hypothetical situation, then a configuration you are getting is busted.
a) I am from Xorg team in Red Hat, so you don't have to explain how EDID data are piece of *. And people who are developing this as well, don't worry. b) The point is to _identify_ the particular piece of hardware, not to blindly follow what EDID suggests. But there is much more to it, which even I don't grok. See a) ;-).
Matěj
On Thu, 2008-10-09 at 12:33 -0600, Michal Jaegermann wrote:
On Thu, Oct 09, 2008 at 05:25:34PM +0200, Matej Cepl wrote:
On 2008-10-08, 22:27 GMT, Tom Horsley wrote:
So, X has achieved the holy grail of no config file by moving all the config files to a far more obscure place and changing them to undocumented xml gibberish?
No, the point of this should be that computer will automagically recognize which device you have and take from the database of configurations
There is a small fly in this ointment. The above may work, usually, but very far from always. For example, if monitor EDID data are faulty or not present at all, and this is _not_ a hypothetical situation, then a configuration you are getting is busted. Also something which is possible, and even "correct" in some sense, does not need to be optimal/desired in a given situation.
It sounds like another of those "90% solutions" which happen to work, more or less, for a developer in her/his particular configuration and which are screwing you often enough.
(and take a look at /usr/share/hal/fdi/policy for illustration should look like)
Yes, I had do that on various occasions. It is never clear what to do with this dreaded XML maze or if what you are trying to hack even has a chance of working. Shudder!
Seriously, people. If there's no xorg.conf file, and you need one, make one.
- ajax
-
"Jóhann B. Guðmundsson" -
Adam Jackson -
Antonio Olivares -
Bruno Wolff III -
Chris Adams -
Jeffrey Ollie -
Jerry Amundson -
Jesse Keating -
Matej Cepl -
Michal Jaegermann -
Rahul Sundaram -
Robert P. J. Day -
Scott Robbins -
Todd Denniston -
Tom Horsley