Edgy X vesa driver blank screen on Toshiba Portege R100

I forgot to mention that the keyboard is unresponsive when the screen is blank, so I either have to press the off button or ssh in from another machine. Incidentally, when I ssh in, X is taking up 99% of the CPU.

I'm also attaching an Xorg.conf and Xorg.0.log.

Here's the Xorg.0.log

I've tried turning off many of the modules including dri and glx, but this doesn't seem to make any difference. Indeed, they are reported as being loaded in the Xorg.log.

This problem may be specific to ubuntu. Under fedora core 6, the vesa driver from xorg 7.1.1 does seem to work on a friend's R100 with the same graphics card.

I've built the deb for the last version of the vesa driver in the dapper repository (1.0.1), and tried this, but with no success.

I thought that this bug might be similar to Bug #61981 or Bug #61979, but disabling the option "hotkeys_over_acpi" in /etc/modprobe.d/toshiba_acpi.modprobe does *not* work as suggested in those bugs.

Nor does booting with acpi=off

I attach the syslog, lpsci and Xorg.0.log for acpi=off

Here's the Xorg.0.log

I also tried an earlier kernel (2.6.15-27) but to no avail.

I can confirm that this problem exists. With the Trident CyberXPm32 we have a serious problem, because the trident driver support is seriously messed up in edgy as well.

I've created a bug report for this at https://bugs.freedesktop.org/show_bug.cgi?id=9050
and linked it back to here.

Update: In the Xorg.0.log, every mode has PhysBasePtr 0xffffffff, whereas in the old (dapper) Xorg.0.log, no mode had PhysBasePtr 0xffffffff, and there were a variety of PhysBasePtrs. When it comes to setting up the write combine range I suspect that this value is being passed to SetWC via VESAMapVidMem and xf86MapVidMem.

In programs/Xserver/hw/xfree86/os-support/linux/lnx_video.c setWC calls mtrr_add_wc_region recursively, and I suspect it is going into a loop.

I have changed vesa.c to force it to use

 pVesa->mapPhys = 0xa0000;
 pVesa->mapSize = 0x10000;

like the old (dapper) log file.

X now starts up with the vesa driver, but its behaviour seems to be
very variable. Once it let me log in, and then crashed as soon as my
mouse went over the GNOME panel, and a few times it gave me the login screen, but no mouse or keyboard input (apart from Ctrl-Alt-F1,
fortunately).

This suggests that pVesa->MapPhys in vesa.c is being found incorrectly by xf86Screens() (or some function it calls), but that perhaps this has other consequences that I haven't realised.

Here's confirmation of the problem from the forums:

http://ubuntuforums.org/showthread.php?p=1769920

I've found a solution for this.
I've a Toshiba Portege R100 and have the same problem.
My solution is to add:
vga=791

to the menu.lst grub file (/boot/grub/menu.lst)

and these settings in xorg.conf

Section "Module"
        Load "bitmap"
        Load "ddc"
# Load "dri"
        Load "extmod"
        Load "freetype"
# Load "glx"
        Load "int10"
        Load "record"
        Load "type1"
        Load "v4l"
        Load "vbe"
EndSection

Section "Device"
        Identifier "Trident Microsystems CyberBlade XP4m32"
        Driver "trident"
        BusID "PCI:1:0:0"
        Option "AccelMethod" "EXA" # [<str>]
        Option "ShadowFB" "False" # [<bool>]
        Option "CyberShadow" "Yes"
EndSection

Now it works fine. Everything.

Good luck.

Sorry, I should be a bit more specific:

In grub file:

title Ubuntu, kernel 2.6.17-11-386
root (hd0,0)
kernel /vmlinuz-2.6.17-11-386 root=UUID=20b09c22-cb1a-478d-bbe7-ca6b6c4 09f1d ro quiet splash vga=791

Thanks for your information manu.

I have a very similar xorg.conf that uses the trident driver like the one posted by manu, and X more-or-less works with some glitches mentioned in http://ubuntuforums.org/showthread.php?t=301082
I may try the vga=791 option to see if that fixes the glitches.

However, this is not the point of this bug, which is specifically about the *vesa* driver. There are two reasons I think vesa is important:
* As I understand it, it's the de facto standard driver. Any card should work with the vesa driver
* AFAIK the trident driver doesn't work with data projectors. I have to admit I haven't tested this with my machine, but a friend's machine with Fedora core 6 and the same version of the trident driver didn't work with a data projector. The vesa driver in dapper used to work, and my friend's FC6 vesa driver worked (cue embarassment on part of this Ubuntu fan).

@manu: Does your config work with data projectors?

@anyone else with this problem: Did you install edgy freshly or did you upgrade from dapper? I've got the impression that fresh installs of edgy were more reliable, but I haven't got round to trying a fresh install myself.

I'm attaching some notes I took while trying to debug this problem. They are very sketchy, and I haven't got round to finding out what the origin of the problem is, but perhaps they might make sense to someone.

Does it work if you boot without splash, ie. remove 'splash' from the kernel options?

Besides, you could try Feisty Herd5 if you have a spare partition..

Thanks for your bug report, could you please try the latest version of Ubuntu and update this bug?

This is on my TODO list - but so are too many other things! I'll need to make an extra partition on my laptop and do a fresh feisty install. I will most definetly update the bug when I get the chance to install feisty.

With a fresh install of Ubuntu704 onto my R100, the install detects "trident" and uses that in the Xorg.conf. X boots fine, and is responsive.

However, when I plug in a data projector to the VGA, I get corrupted screen on both the data projector and the laptop (it did work once, but I had the data projector plugged in during boot; when I swirched Fn-F5 to deactivate data projector, and then Fn-F5 to activate it again, I get the corrupted screen.

VESA driver seemed not to work. Disk churned and no X display.

This might be of relevance from a SUSE user:

https://bugzilla.novell.com/show_bug.cgi?id=248775

Stephen

[Expired for xserver-xorg-video-vesa (Ubuntu) because there has been no activity for 60 days.]

I've tried (in Edgy) with the splash option to the kernel disabled (and no vga=791 arguement) and get the same problem (X goes into an infinite loop). The Xorg.0.log is attached. The PhysBasePtr is still set to 0xffffffff

I've tried (in Edgy) with the splash option to the kernel disabled (and no vga=791 arguement) and get the same problem (X goes into an infinite loop while trying to set the write-combining range). The Xorg.0.log is attached. The PhysBasePtr is still set to 0xffffffff

I have done a clean install of Hardy on the laptop, and the VESA driver now works. Still need to work out how to get the external video working, but I think if there is a problem there, it would be a separate bug.