Latest mod to xorg makes X unusable on Toshiba laptop

[Tjarn]

I run my laptop with a virtual resolution of 1600 x 1200 in a physical resolution of 1024 x 768. It's worked nicely for years. Some genius has decided to destroy the possibility and knows much better than I do how I should be allowed to run my display.

An update from the 10th, 11th, or 12th of October rewrote my xorg.conf to make the virtual display 1024x768. When I hand edit it to the correct 'Virtual 1600 1200' it workd for a bit then killed the x session. Replacing the xorg.conf with one that worked on previous versions or on Feisty give all sorts of 'interesting' results. Basically it limits me to the physical display size -- and that's TOTALLY UNACCEPTABLE.

If the genius who screwed this up royally wants to discuss how irritated this makes me, I can be reached at <email address hidden>, or <email address hidden> when I manage to unload the mangled remains of Gutsy and either fall back to Feisty or check out some of the other distributions.

NOTE: If you quit screwing with the stuff after the word 'Virtual' you'd be just fine! I think that the screen tool looks like something useable if you can quit messing up perfectly useable configurations. I'll see if there's a way to nuke it out of existence and see if I can still use Gutsy.

[Tjarn (tjarn)]

After deleting the xorg.conf file and all the backups -- and the xorg.conf.failsafe ones to try to force it to a useable state, leaving only the hand-edited xorg.conf it smears X completely. Evidently whatever changes have been made ignore the 'Virtual' keyword and attempt to use the virtual size as the physical size. The behaviour that I expect is to see 1024x768 window into a 1600x1200 space that drags when I move the pointer past the edge of the real screen. I've fallen back to Feisty and will check as time goes on to see if I can figure a work-around. I don't know how many folks actually use virtual screens, but I'm totally dependent on them. Can't even use Gutsy for more than a quick boot into it -- yep still broken -- reboot into a useable state.

[Tjarn (tjarn)]

OK here's my workaround. It's a pain in the fundament, but does get me going. I reconfigure X to get the crippled xorg.conf file that lets me run. That gets me going in the crippled 1024x768 screen. I copy a working xorg.conf file from a working Feisty installation and write it over the crippled xorg.conf Then a <ctl><alt><backspace> nukes X. When it comes up I can use the screen configuration tool and select 1600x1200 and run for that session. It won't survive a reboot -- I then have to nuke the xorg.conf and replace the crippled one with one that will work. Some observations: The crippled xorg.conf loses the additonal color depth entries. There are times that I need those as well. Whatever the reason for the rewrite of the xorg.conf file on reboot, the execution sucks. xorg isn't broken, it's the way xorg.conf is getting fucked up that's the problem.

[Tormod Volden (tormodvolden)]

Thanks for your report and prose. Which driver are you using? Can you please attach conf and log files?

[Tjarn (tjarn)]

Sent tar.gzipped files in e-mail, attaching the various files here... Xorg log file, useable.x.conf and x.conf that has been mangled. At this point, the mangled x.conf file will run, but has lost all the color depth entries except 24 (I have some reasons for using 16 fairly often) and has nuked the 'Virtual 1600 1200' line and written 'Vitual 1024 768' -- fine for the physical display, but the point of using the virtual display is to access a larger image space with a limited physical display.

[Tjarn (tjarn)]

here is the useable.xorg.conf that I write over the crippled one that it thinks I shoujld use.

[Tjarn (tjarn)]

And lastly, from /var/log -- the tracks of what it thought it was doing. This is from the last bootup.

What I must do in order to work, is to run the following script:

#!/bin/bash
#fix xorg.conf resolution --
#
sudo rm /etc/X11/xorg.conf.*
sudo cp /etc/X11/useable.xorg.conf /etc/X11/xorg.conf
echo "<ctl><alt><Backspace> to restart X"

#check to see that we've got a useable one

grep Virtual /etc/X11/xorg.conf

After restarting the x server and logging in, I can use the screen configuration tool to get a useable virtual screen. If I could figure a way to keep its grubby paws of my xorg.conf i'd be fine. I'd be happy to drive a stake through the damn thing's heart. (I'd be ecstatic if there were a way to configure it to not run unless asked for!)

[Tormod Volden (tormodvolden)]

Have you tried the "intel" driver instead of "i810"?

[Tormod Volden (tormodvolden)]

Please also try without any xorg.conf. The xorg.conf is usually not modified automatically. Do you use the "Screen and Graphics" GUI? It will rewrite your xorg.conf...

[Tjarn (tjarn)]

OK will try the 'intel' driver, and will try without any xorg.conf file. Yes, I use the 'Screen and Graphics' gui. It's the only way that I can get the 1600 x 1200 display back. Without using it, I end up with my useable.xorg.conf changed to the one you see. Hmmm... Is this a rational test plan?
1. boot with no xorg.conf -- I'll tell you results and copy you if xorg.conf produced.
2. If xorg.conf produced try to add the 'Virtual 1600 1200 ' line that I need. I'll restart X with that and tell you results and send you the before and after xorg.conf files.
2b. If no xorg.conf file produced, I'll copy my useable.xorg.conf to xorg.conf and restart X. I'll send you the file without using the screen&graphics gui.

Both cases I'll not use the screen and graphics gui.

I'll follow that basic pattern and try to give you a more detailed report.

[Tormod Volden (tormodvolden)]

A new xorg.conf is usually not generated, only if you use "Screen and Graphics" or "sudo dpkg-reconfigure -phigh xserver-xorg". Try without one and attach the resulting Xorg.0.log. Then use dpkg-reconfigure to generate one and add the Virtual line.

For the moment I am interested in what the auto-detection does, and not what the "Screen and Graphics" can make up.

[Tjarn (tjarn)]

OK -- will do that. I've determined that my particular problem is caused by this sequence:
1 -- editing xorg.conf to add the line Virtual 1600 1200 (or replacing with one that is correct)
2 -- booting or restarting X -- gdm gives login, login results in a screen not using the virtual size, rather the physical size.
3 -- running the 'Screens and Graphics' tool and selecting the 1600x1200 screen. This comes up and works correctly. However -- the xorg.conf file is destroyed at this point.
Subsequent boots or x restart are mixed. I've had them totally lock, come up in 640x480 mode, and really be a mess or fail to work entirely. With no xorg.conf it does come up in a crippled (no 1600x1200 virtual window) but useable mode. As long as I don't try to use the xorg.conf file that Screens and Graphics poops out I can replace it with a good file and then run. I have determined that if i use xdm instead of gdm it respects my xorg.conf virtual setting. In this scenario, the only downside is needing to use 'shutdown -h now' to stop my session.

This bug is actually two interrelated bugs.

1: gdm does not respect the xorg.conf 'virtual' line.
2: displayconfig-gtk has no clue as to dealing with the 'virtual' line and totally screws up what it writes

At this point deleting the xorg.conf file results in a limited display that can be used for troubleshooting (although not my real work). I am assuming that this is your interest. If so, my congratulations on getting something that works this well.

I've completely deleted gdm from my machine. Any logs that I send from this point are done under xdm (I don't think that will affect what you're working on, but want you to be aware). I'll be sending the Xorg.0.log next comment.

[Tjarn (tjarn)]

OK, have removed xorg.conf and rebooted. I'm running in a 1024x768 screen (it looks like) and it feels like i'm wearing a straight jacket. I am attaching the Xorg.0.log file that was generated on bootup from cold.

As this installation was upgraded during development, I've grabbed an installation ISO from BitTorrent and will burn and install it on another partition and see if I have the same problems there. More on that as time allows.

I'll run "sudo dpkg-reconfigure -phigh xserver-xorg" next and see what it generates.

[Tjarn (tjarn)]

Modified the dpkg-reconfigure file and have booted with it. It does not recognize the 'virtual' line. I'm adding the dpkg-reconfigure file to the attachments. I'll wait until you let me know what actions will help the most.

I see another Xorg.0.log generated on boot. Will attach that as well.

[Tjarn (tjarn)]

This is the Xorg.0.log generated when I booted with the xorg.conf generated by the dpk-reconfigure command. At this point I still do not have my 1600x1200 virtual display, and only have the default (24) depth. I notice that the log file is shorter than the last. Do you want one created when booting from the useable xorg.conf?

[Tormod Volden (tormodvolden)]

Just to be sure, is this bug about: you can not have a virtual screen size that allows you to pan around? Can you update the title and description so it is more clear what the problem is? Like expected versus observed behaviour. Please try to be as concise, clear and technically precise as possible.

You are right, "2: displayconfig-gtk has no clue" is a separate (and known) issue. I am primarily interested in having the screen set up automatically without using such tools. BTW, as you maybe read in the Release Notes, the new intel driver uses xrandr1.2 which displayconfig-gtk doesn't support yet.

[Tormod Volden (tormodvolden)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!