Ever since the behavior of having Xorg guess resolutions has been implemented, I have little to no luck with it.
Of at least 6 fedora installs I've done since then it has never guessed a resolution that is comfortable (for lack of a better word) and on some occasions it has required rebooting into runlevel 3 - not exactly a problem, but not very friendly. That ranges from desktop to laptops, native to VM ( Parallels ) and standard to widescreen displays.
It has deterred a computer savvy friend of mine from using Fedora because on both attempts, installation went fie, but Xorgs choice of resolution through his LCD into panic in which it turns off (forgot the message it prints) - again, fairly easy for me to fix, but he doesn't know how exactly and so has put it of, busy people.
Most annoying to me however is that I must put on my monitor, at least before the gdm/kdm or i get a bloated, unusable resolution, it as simple as Ctrl+Alt+Backspace but it is still quite annoying. I had set several modes, now I have it down to just `Modes "1280x960"` and still that behavior continues, I'm not sure why it doesn't trust my xorg.conf.
I have a ViewSonic PF790 display and my Smolt UUID is 'a141fbad-6bc1-419a-a5e7-1c247d90184a' if that helps.
I should add that it did guess right on my laptop, but that might be because my laptop only does 1024x768 and 800x600 - limited options
Arthur Pemberton
I forgot to mention that my desktop uses the 'nvidia' driver, however, it was no better at guessing with the 'nv' driver.
On Sat, Sep 15, 2007 at 01:46:03AM -0500, Arthur Pemberton wrote:
Ever since the behavior of having Xorg guess resolutions has been implemented, I have little to no luck with it.
It's been pretty good to me. What video cards are you using?
On 9/15/07, Matthew Miller mattdm@mattdm.org wrote:
On Sat, Sep 15, 2007 at 01:46:03AM -0500, Arthur Pemberton wrote:
Ever since the behavior of having Xorg guess resolutions has been implemented, I have little to no luck with it.
It's been pretty good to me. What video cards are you using?
Aside from the one in my smolt profile, I've also attempted in Parallels on a Mac, and I believe an embedded Nvidia chipset on an HP machine, sorry, can't recall details more than this
Arthur Pemberton wrote:
On 9/15/07, Matthew Miller mattdm@mattdm.org wrote:
On Sat, Sep 15, 2007 at 01:46:03AM -0500, Arthur Pemberton wrote:
Ever since the behavior of having Xorg guess resolutions has been implemented, I have little to no luck with it.
It's been pretty good to me. What video cards are you using?
Aside from the one in my smolt profile, I've also attempted in Parallels on a Mac, and I believe an embedded Nvidia chipset on an HP machine, sorry, can't recall details more than this
It might be worth taking a look at how debian and ubuntu do it, with dexconf and xdebconfigurator -
http://www.penguin-soft.com/penguin/man/8/xdebconfigurator.html
I'm still trying to figure out how dexconf, via xdebconfigurator I believe, seems to more correctly configure X to use 1024x768 or larger under qemu, wheras xorg by itself as is configured with f7/f8t2 only comes up in 800x600, which looks pretty lame.
I don't know if getting xdebconfigurator to work on fedora is possible. It looks like a conglomeration of various tools, none of which is apparently yet so capable that debian/ubuntu feel it can be relied on exclusively.
For instance, I suspect the -r option uses this read-edid tool, which I was using on a mandrake livecd I built 6 years ago, to good effect.
If you want to try it out to see what it is capable of, I suggest just burning and booting ubuntu-7.04, or perhaps a recent build of the debian-gnome-livecd
http://live.debian.net/cdimage/weekly-builds/
Good luck,
-dmc
On Sat, 2007-09-15 at 16:30 -0500, Douglas McClendon wrote:
Arthur Pemberton wrote:
On 9/15/07, Matthew Miller mattdm@mattdm.org wrote:
On Sat, Sep 15, 2007 at 01:46:03AM -0500, Arthur Pemberton wrote:
Ever since the behavior of having Xorg guess resolutions has been implemented, I have little to no luck with it.
It's been pretty good to me. What video cards are you using?
Aside from the one in my smolt profile, I've also attempted in Parallels on a Mac, and I believe an embedded Nvidia chipset on an HP machine, sorry, can't recall details more than this
It might be worth taking a look at how debian and ubuntu do it, with dexconf and xdebconfigurator -
http://www.penguin-soft.com/penguin/man/8/xdebconfigurator.html
I'm still trying to figure out how dexconf, via xdebconfigurator I believe, seems to more correctly configure X to use 1024x768 or larger under qemu, wheras xorg by itself as is configured with f7/f8t2 only comes up in 800x600, which looks pretty lame.
X can't tell when it's running under qemu. All it knows is that it's talking to something that looks like an old Cirrus Logic card. The qemu authors have repeatedly refused to give X any hint that it's really something better so we can pick larger resolutions by default.
- ajax
On Sat, 2007-09-15 at 01:46 -0500, Arthur Pemberton wrote:
Ever since the behavior of having Xorg guess resolutions has been implemented, I have little to no luck with it.
Of at least 6 fedora installs I've done since then it has never guessed a resolution that is comfortable (for lack of a better word) and on some occasions it has required rebooting into runlevel 3 - not exactly a problem, but not very friendly. That ranges from desktop to laptops, native to VM ( Parallels ) and standard to widescreen displays.
I'm missing some details here. You say it guesses wrong, but don't say what it guesses, or what you would prefer.
I do have an idea for choosing better, but it's really hard to heuristic this properly. Partly because the X drivers are still limited and can't resize _up_ from whatever it chooses initially.
- ajax
On 9/17/07, Adam Jackson ajackson@redhat.com wrote:
On Sat, 2007-09-15 at 01:46 -0500, Arthur Pemberton wrote:
Ever since the behavior of having Xorg guess resolutions has been implemented, I have little to no luck with it.
Of at least 6 fedora installs I've done since then it has never guessed a resolution that is comfortable (for lack of a better word) and on some occasions it has required rebooting into runlevel 3 - not exactly a problem, but not very friendly. That ranges from desktop to laptops, native to VM ( Parallels ) and standard to widescreen displays.
I'm missing some details here. You say it guesses wrong, but don't say what it guesses, or what you would prefer.
For lack of me knowing how to get the current resolution at the console level, coupled with bad memory, I can't say that I remember the exact values that it gets wrong. What it gets wrong, is the attempted screen resolutions, often using out of range (for LCDs) or extreme ( very small or very large) resolutions.
I do have an idea for choosing better, but it's really hard to heuristic this properly. Partly because the X drivers are still limited and can't resize _up_ from whatever it chooses initially.
I'm not sure that I understand what you're saying here.
Still, why does xorg _not_ use what's in xorg.conf just because the monitor is off?
On Mon, 2007-09-17 at 18:52 -0500, Arthur Pemberton wrote:
On 9/17/07, Adam Jackson ajackson@redhat.com wrote:
On Sat, 2007-09-15 at 01:46 -0500, Arthur Pemberton wrote:
Ever since the behavior of having Xorg guess resolutions has been implemented, I have little to no luck with it.
Of at least 6 fedora installs I've done since then it has never guessed a resolution that is comfortable (for lack of a better word) and on some occasions it has required rebooting into runlevel 3 - not exactly a problem, but not very friendly. That ranges from desktop to laptops, native to VM ( Parallels ) and standard to widescreen displays.
I'm missing some details here. You say it guesses wrong, but don't say what it guesses, or what you would prefer.
For lack of me knowing how to get the current resolution at the console level, coupled with bad memory, I can't say that I remember the exact values that it gets wrong. What it gets wrong, is the attempted screen resolutions, often using out of range (for LCDs) or extreme ( very small or very large) resolutions.
xrandr or xdpyinfo will tell you.
I do have an idea for choosing better, but it's really hard to heuristic this properly. Partly because the X drivers are still limited and can't resize _up_ from whatever it chooses initially.
I'm not sure that I understand what you're saying here.
I have to guess at an initial screen size. I can't _know_ what the physical size in pixels is, because the monitor does not tell me. It doesn't even tell me whether "physical size in pixels" is a meaningful concept for the monitor type, or whether it's a CRT or an LCD, or lots of other things that would be useful information. It merely tells me some modes and sync ranges that it claims it can support, and a hint about which mode it prefers.
The hint about which mode it prefers is often garbage. 1280x1024 is not a good mode for a 4:3 monitor. Your shiny new HDTV will claim to be 1280x720 even though it's physically 1360x768. And so forth. So what I do instead is try to deduce the aspect ratio of the screen, and then go for the largest mode that will match, preferring the mode the monitor reports as "preferred" if it matches aspect ratio. This happens to pick some really huge resolutions on CRTs sometimes, but I'd rather guess too large than too small.
The reason I'd rather guess too large is, for any given run of the X server, the initial mode is also the largest mode in the mode pool, and is the largest mode you can get for that instance of the X server. So the user can RANDR down to the resolution they want - and gdm will remember it, and set that mode the next time they log in - but you can't RANDR up. Also because, really, you can make the UI bigger quite easily, but shrinking things smaller than a pixel is sort of tricky.
So, like, if I had some heuristic for guessing "oh yeah, that's a CRT", then I could try to clamp the upper bound of resolutions to, say, no more than 130dpi or something. But I'd hate to implement that and then find someone with a 150dpi LCD that we don't set the native panel size on just because we don't think pixels get that small.
Does this clarify the tradeoffs at all?
Still, why does xorg _not_ use what's in xorg.conf just because the monitor is off?
If the monitor is off, I can't talk to it, so I can't ask it what it can do. Note that this is something of a lie, most monitors made since, oh, 2000, will merely look like they're asleep but will still respond over DDC if they have a power cord plugged in.
But if I can't talk to it, I'll use what's in the config file. Do you have an example of X not doing so?
- ajax
On 9/18/07, Adam Jackson ajackson@redhat.com wrote:
If the monitor is off, I can't talk to it, so I can't ask it what it can do. Note that this is something of a lie, most monitors made since, oh, 2000, will merely look like they're asleep but will still respond over DDC if they have a power cord plugged in.
But if I can't talk to it, I'll use what's in the config file. Do you have an example of X not doing so?
Yes... the most frustrating part of all. As I've been trying to communicate, xorg does _not_ use my xorg.conf when the monitor is off, and instead uses something on the scale of 800x600 which is so large, the necessary widgets are off screen.
Arthur Pemberton wrote:
On 9/18/07, Adam Jackson ajackson@redhat.com wrote:
If the monitor is off, I can't talk to it, so I can't ask it what it can do. Note that this is something of a lie, most monitors made since, oh, 2000, will merely look like they're asleep but will still respond over DDC if they have a power cord plugged in.
But if I can't talk to it, I'll use what's in the config file. Do you have an example of X not doing so?
Yes... the most frustrating part of all. As I've been trying to communicate, xorg does _not_ use my xorg.conf when the monitor is off, and instead uses something on the scale of 800x600 which is so large, the necessary widgets are off screen.
You need to provide more information including your hardware and xorg configuration for others to reproduce and fix any issues. Might be better in a bug report.
Rahul
On 9/18/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
Arthur Pemberton wrote:
On 9/18/07, Adam Jackson ajackson@redhat.com wrote:
If the monitor is off, I can't talk to it, so I can't ask it what it can do. Note that this is something of a lie, most monitors made since, oh, 2000, will merely look like they're asleep but will still respond over DDC if they have a power cord plugged in.
But if I can't talk to it, I'll use what's in the config file. Do you have an example of X not doing so?
Yes... the most frustrating part of all. As I've been trying to communicate, xorg does _not_ use my xorg.conf when the monitor is off, and instead uses something on the scale of 800x600 which is so large, the necessary widgets are off screen.
You need to provide more information including your hardware and xorg configuration for others to reproduce and fix any issues. Might be better in a bug report.
Rahul
I have already provided my Smolt UUID (a141fbad-6bc1-419a-a5e7-1c247d90184a), monitor band/model (ViewSonic PF790), and here is my xorg.conf, http://www.pembo13.com/pub/xorg.conf.watson.20070918
If there is any more information I can let me know, if not, I will elevate this to a bug report.
Arthur Pemberton
On Tue, 2007-09-18 at 11:25 -0500, Arthur Pemberton wrote:
On 9/18/07, Adam Jackson ajackson@redhat.com wrote:
If the monitor is off, I can't talk to it, so I can't ask it what it can do. Note that this is something of a lie, most monitors made since, oh, 2000, will merely look like they're asleep but will still respond over DDC if they have a power cord plugged in.
But if I can't talk to it, I'll use what's in the config file. Do you have an example of X not doing so?
Yes... the most frustrating part of all. As I've been trying to communicate, xorg does _not_ use my xorg.conf when the monitor is off, and instead uses something on the scale of 800x600 which is so large, the necessary widgets are off screen.
Perhaps I wasn't sufficiently clear about this. If you could feed me an X log and config file from this failure condition, I might be able to figure out why it looks like we're ignoring your settings.
The likely explanation is that your Monitor section is either missing, or doesn't contain any information about the sync ranges and etc. Which means it doesn't describe your monitor at all, so we have to assume something conservative like 800x600. If your favorite app doesn't fit in that size, then it's violating the Gnome HIG to begin with.
It's generally not sensible to try to infer what monitor capabilities the user meant based on what modes they asked for. If I ask for 2048x1536 on a monitor that can't do it, I might be able to set up the card to scan out that timing, but the monitor's just not going to sync, and it's _much_ better to fail in a way that the user can see and interact with, than fail to black.
- ajax
On 9/18/07, Adam Jackson ajackson@redhat.com wrote:
On Tue, 2007-09-18 at 11:25 -0500, Arthur Pemberton wrote:
On 9/18/07, Adam Jackson ajackson@redhat.com wrote:
If the monitor is off, I can't talk to it, so I can't ask it what it can do. Note that this is something of a lie, most monitors made since, oh, 2000, will merely look like they're asleep but will still respond over DDC if they have a power cord plugged in.
But if I can't talk to it, I'll use what's in the config file. Do you have an example of X not doing so?
Yes... the most frustrating part of all. As I've been trying to communicate, xorg does _not_ use my xorg.conf when the monitor is off, and instead uses something on the scale of 800x600 which is so large, the necessary widgets are off screen.
Perhaps I wasn't sufficiently clear about this. If you could feed me an X log and config file from this failure condition, I might be able to figure out why it looks like we're ignoring your settings.
I will get you the logs once I get back to the machine, my xorg.conf has already been provided.
The likely explanation is that your Monitor section is either missing, or doesn't contain any information about the sync ranges and etc. Which means it doesn't describe your monitor at all, so we have to assume something conservative like 800x600.
Am I required to manually put in my Monitor section? If so, then going down to 800x600 is the default behaviour.
If your favorite app doesn't fit in that size, then it's violating the Gnome HIG to begin with.
In this case, it is the login screen, KDM
It's generally not sensible to try to infer what monitor capabilities the user meant based on what modes they asked for. If I ask for 2048x1536 on a monitor that can't do it, I might be able to set up the card to scan out that timing, but the monitor's just not going to sync, and it's _much_ better to fail in a way that the user can see and interact with, than fail to black.
- ajax
Well it seems like many of the current assumptions result in cases where the end result is "unfriendly", considering that my hardware setup isn't exotic, and my software (in terms of Xorg) is near vanilla.
On 9/18/07, Adam Jackson ajackson@redhat.com wrote:
On Tue, 2007-09-18 at 11:25 -0500, Arthur Pemberton wrote:
Yes... the most frustrating part of all. As I've been trying to communicate, xorg does _not_ use my xorg.conf when the monitor is off, and instead uses something on the scale of 800x600 which is so large, the necessary widgets are off screen.
Perhaps I wasn't sufficiently clear about this. If you could feed me an X log and config file from this failure condition, I might be able to figure out why it looks like we're ignoring your settings.
Here is an appropriate log: http://www.pembo13.com/pub/Xorg.0.log
On 9/18/07, Adam Jackson ajackson@redhat.com wrote:
The reason I'd rather guess too large is, for any given run of the X server, the initial mode is also the largest mode in the mode pool, and is the largest mode you can get for that instance of the X server. So the user can RANDR down to the resolution they want - and gdm will remember it, and set that mode the next time they log in - but you can't RANDR up. Also because, really, you can make the UI bigger quite easily, but shrinking things smaller than a pixel is sort of tricky.
Good point about not being able to RANDR up, however you can system-config-display up. If your display blanks out due to high resolution, you can't RANDR down, system-config-display, or for most, use said machine to get online assistance. If th display blanks out, the text make be too small for some to read and navigate to a tool the know nothing about called RANDR (maybe it has a better name in the Gnome menu)
desktop@lists.fedoraproject.org