Top rows of screen botched on Toshiba Libretto U105

[era]

Binary package hint: xserver-xorg-video-i810

My Toshiba Libretto U105 starts up with the top of the screen (maybe top 25 pixel rows or so) filled with odd litter.

For example, while the Feisty Live CD boots, it's filled with green pixels which repeat some system start-up message; the pixels are offset so it cannot easily be read but it looks like "uncompressing kernel ....." or some such, with a lot of periods appearing like they do during a non-graphical boot.

Once the system is up, the mouse cursor is also badly wounded or completely missing. If I hadn't discovered the following workaround, the system would be completely unusable at this point.

As a workaround, cycling the display with fn+F5 a few times (external display + internal LCD; external only; back to internal only) clears up the situation. After waking up after a suspend, I have to cycle the display again to get a working screen.

I have been running Edgy with this workaround for a few months, but decided to try installing Feisty from scratch in case this would help solve this problem. Alas, I still have the same problem under Feisty.

I have a strong suspicion that this is identical to Debian bug http://bugs.debian.org/362977 but I could be wrong, of course.

[Faré (fahree)]

I ran the 7.0.0 server with the driver from the 6.9.0 server, and it works fine.
The 7.0.0 module (non-working) is 1.5.1, and the 6.9.0 module (working) is
1.4.1. The 1.4.1 module also allocates the ring buffer first, but somehow
manages to correctly tell the video card about the framebuffer being offset 128KiB.

I can do more tests if you need them to locate the bug...

[Alanh-fairlite (alanh-fairlite)]

you should probably either get the 1.5.2 version of grab the git repository and
build yourself.

[Faré (fahree)]

Do you have a i686 binary module to test the bug? I lack time to setup a rebuild
at this time...

If 1.5.2 is known to fix this problem, I suppose you can close this bug. -- but
I still appreciate an updated binary driver.

[Alanh-fairlite (alanh-fairlite)]

You can get a new module from http://www.fairlite.demon.co.uk/intel.html

[Faré (fahree)]

The ABI of this module is not compatible with my current server from the latest
debian (7.0.22), and so I cannot test it. I tried to get instructions for
compiling a whole server, but between git and cvs and a huge list of modules, I
don't know where to start. Is it possible that you should either post clear
directions on what to compile (and how), or publish a full tarball of related X
server binaries to test in a chroot?

[Alanh-fairlite (alanh-fairlite)]

Use the -ignoreABI flag to the Xserver.

[Faré (fahree)]

Created an attachment (id=6180)
error output of X server with i810_drv 1.6.0 on Libretto U105

I finally tried the module with said server flag. Sorry for the delay.

It is a definite improvement in two ways:
(1) the zone of lost screen is much reduced (something between 10 and 20 lines)

(2) it is now aligned with the line length, so there is no horizontal shift
(3) the patterns only eventually fill half of that space.

Relevant lines in X error output:
(WW) module ABI major version (1) doesn't match the server's version (0)
(EE) I810(0): [dri] DRIScreenInit failed. Disabling DRI.
The X server error output ends abruptly, but more information is logged in
/var/log/Xorg.1.log (attached -- and thanks to strace -e open for finding it).

[Alanh-fairlite (alanh-fairlite)]

From the look of that log, you've got a nicely broken Video BIOS.

Try adding.

Option "MonitorLayout" "NONE,LFP"

to your Device section.

[Faré (fahree)]

Created an attachment (id=6181)
X log with MonitorLayout NONE,LFP

Here's the output with the option you recommended.
Only the few top lines were visible, and with the cursor double sized, so the
whole mode switching must have failed. The bottom of the screen was monochrome,
black or white depending on my moving the cursor.

With "LFP,NONE" instead, the whole screen remained black.

Sorry about my Video BIOS being broken -- I don't think I can change it, and
the old driver knew how to work around that brokenness, so I suppose it's
possible...

[Faré (fahree)]

BTW, thanks a lot for your support and prompt replies!

[Alanh-fairlite (alanh-fairlite)]

Do you have a CRT plugged in when you boot up ??

If so, can you disconnect it ?

And try again.

[Alanh-fairlite (alanh-fairlite)]

If that doesn't work, you may want to try getting the modesetting branch from
the git repository for the xf86-video-intel driver which does away with the
VideoBIOS to set the modes.

It should certainly help you in your case.

[Faré (fahree)]

No CRT plugged in at bootup or at anytime.

May I similarly request a i386 binary driver for the modesetting branch?

(What new feature confuses the BIOS that wasn't used in previous versions?
Can't we allocate those buffers *after* the framebuffer instead of *before*?)

[H9826214 (h9826214)]

Created an attachment (id=6570)
X log

I am suffering from the same problem (I guess) since the Debian upgrade of the
xorg xserver in unstable. I experienced the displaced framebuffer and could not
get it to work ever since.

I compiled the latest git version of the xserver and the intel driver module
(main branch and modesetting branch). The attached log shows the result when I
try the modesetting branch (but it's the same for the main branch intel
driver). It seems that the driver does not detect any modes and aborts. I'd be
very grateful for suggestions. Thanks!

[Faré (fahree)]

Short update: the bug is still there with driver 1.6.5, no change since last
time (i.e. 10 to 20 lines lost on top of the screen, but now it's aligned to a
1280-pixel line, so what remains of the screen is kind of usable).

Once again, can't we just allocate those scratch areas (or whatever they are)
after the framebuffer? That would make them invisible.

[Alanh-fairlite (alanh-fairlite)]

Like I said in comment #12 - try the modesetting branch.

[Alanh-fairlite (alanh-fairlite)]

(In reply to comment #14)
> Created an attachment (id=6570) [edit]
> X log
>
> I am suffering from the same problem (I guess) since the Debian upgrade of the
> xorg xserver in unstable. I experienced the displaced framebuffer and could not
> get it to work ever since.
>
> I compiled the latest git version of the xserver and the intel driver module
> (main branch and modesetting branch). The attached log shows the result when I
> try the modesetting branch (but it's the same for the main branch intel
> driver). It seems that the driver does not detect any modes and aborts. I'd be
> very grateful for suggestions. Thanks!

Try adding

Option "NoDDC"

and see if that helps.

[Faré (fahree)]

Doesn't help much. It possibly reduces the size of the lost zone further, but I
haven't measured. There still is a lost zone, anyway.

[Alanh-fairlite (alanh-fairlite)]

post a log.

[Alanh-fairlite (alanh-fairlite)]

and a screenshot of the problem would be useful too.

[Faré (fahree)]

Created an attachment (id=7170)
Log with the Option "NoDDC" "True" commented out

Same difference

[Faré (fahree)]

Created an attachment (id=7171)
no visibl diffeence

[Faré (fahree)]

Created an attachment (id=7172)
requested picture

Captured with fbgrab during an attempt to run X with the framebuffer enabled.
The X frambuffer is shifted downwards with the same top on top. The bottom of
the picture seems hosed too, but on screen it shows great.

[Faré (fahree)]

(From update of attachment 7172)
Only the top of this picture is valid. It shows what the top of the screen
looks like when I'm using version 1.6 of the driver later (1.5 is even worse,
since this stuff is not even line-aligned).

The bottom of the screen (below the 16 or so lines) is fine for me, but I could
not capture it with fbgrab.

The bug also happens when I run w/o kernel framebuffer.

[Alanh-fairlite (alanh-fairlite)]

Those logs are not with the modesetting branch. Try again.

[Faré (fahree)]

Darn, I had just grabbed the binary from debian.

Where can I get binaries from the modesetting branch?
Or a compilable tarball of the sources?

[Alanh-fairlite (alanh-fairlite)]

you'll have to checkout the git repo. look at the wiki on wiki.freedesktop.org
and there's information there about getting the git repos.

If you've any specific problems with retrieving the repo then use the xorg
mailing list for help.

[Faré (fahree)]

Getting the source was easy enough: it was the example given in
http://wiki.x.org/wiki/GitPage
   git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel
However, once there, I found that I couldn't get it working with either automake
1.4 or 1.9. With 1.4, I get an early error message about AM_CFLAGS. Upgrading to
1.9, I get up to a point where ./configure borks:
./configure: line 20685: syntax error near unexpected token `XINERAMA,'
./configure: line 20685: `XORG_DRIVER_CHECK_EXT(XINERAMA, xineramaproto)'

In case it matters, I'm using debian testing as my base system. What should I do
from there to get the thing to compile? Pointers to proper Wiki pages welcome...

[Alanh-fairlite (alanh-fairlite)]

As in the previous comment. Any build issues like this should be discussed on
the mailing lists.

[Alanh-fairlite (alanh-fairlite)]

Although I will say it just sounds like you need to install xineramaproto from
the debian packages.

[Alanh-fairlite (alanh-fairlite)]

Also, once you've checked out the git repo - really make sure you are using the
modesetting branch by doing....

git checkout modesetting

before doing any compilation.

[Faré (fahree)]

OK, after installing a lot of other packages, I managed to compile things.
git checkout modesetting was almost instantaneous and with no output. Hope it
worked.

Which object file should I use? src/.libs/i810_drv.so? When I use it, I get the
following error when the server tries to load it:
dlopen: /usr/lib/xorg/modules/drivers/i810_drv.so: undefined symbol:
I830xf86DefaultModes
Am I doing something wrong? Do I first have to recompile the whole server or
something like that? What exactly must I compile from which source, and what can
I leave from my debian system?

[Alanh-fairlite (alanh-fairlite)]

Check that it's built all the .c files to .o as it sounds like i830_xf86Modes.c
isn't getting built.

[Faré (fahree)]

Woohoo! The modesetting branch works perfectly for me, with or without option
NoDDC. Congratulations!

Does that mean I can now use lots of weird resolutions and let the hardware do
the stretching for me? Or does the XV and/or GL2 support make this notion
obsolete anyway?

Anyway, the battle was hard, but you've made it worthwhile. Thanks a lot, and
sorry for being so annoying. Question remaining: when will the branch become
mainline and be released?

NB: the bug with I830xf86DefaultModes was due to "make clean" being not enough.
I needed to make distclean or something and regenerate the Makefile's.

[Faré (fahree)]

Created an attachment (id=7214)
Binary driver as compiled from the modesetting branch on debian testing i386

For the sake of other testers too lazy to go through all the process and
trusting enough to download a binary from the internet, here's the driver I
compiled. (Not that compiling unaudited source code is any less trusting. The
real downside is that my binary won't automagically include new fixes and
improvements in the source since I compiled it.)

NB: I needed to make real clean, delete config.guess and rerun the whole
autogen.sh because I had compiled before I git checkout modesetting.

PS: you might wanna strip the .so for a slight space improvement. Left
unstripped for debugging purposes.

Kisses to Alan!

[H9826214 (h9826214)]

Created an attachment (id=7215)
X log

No change here, I built the latest driver from the modesetting branch, but I
still get basically the same log. I disabled most extensions in my xorg.conf
and added NoDDC, but that didn't help either. Any suggestions? Thx

[Faré (fahree)]

As a downside to the modesetting driver, I find that (on my machine) it's not
possible anymore to switch back to text mode. Whether with the VGA text mode or
the intelfb driver, the screen is garbled when you switch to text mode. Happily,
you can switch back to X.

[era (era)]

Binary package hint: xserver-xorg-video-i810

My Toshiba Libretto U105 starts up with the top of the screen (maybe top 25 pixel rows or so) filled with odd litter.

For example, while the Feisty Live CD boots, it's filled with green pixels which repeat some system start-up message; the pixels are offset so it cannot easily be read but it looks like "uncompressing kernel ....." or some such, with a lot of periods appearing like they do during a non-graphical boot.

Once the system is up, the mouse cursor is also badly wounded or completely missing. If I hadn't discovered the following workaround, the system would be completely unusable at this point.

As a workaround, cycling the display with fn+F5 a few times (external display + internal LCD; external only; back to internal only) clears up the situation. After waking up after a suspend, I have to cycle the display again to get a working screen.

I have been running Edgy with this workaround for a few months, but decided to try installing Feisty from scratch in case this would help solve this problem. Alas, I still have the same problem under Feisty.

I have a strong suspicion that this is identical to Debian bug http://bugs.debian.org/362977 but I could be wrong, of course.

[Bryce Harrington (bryce)]

Hi era,

Thanks for reporting the bug and looking up a similar one upstream. Could you also attach your /etc/X11/xorg.conf and /var/log/Xorg.0.log files? Also, if possible, it could be helpful to have either a screenshot or photograph of your screen.

I'll mark this as affected by xorg bug 6635.

It sounds like this may be fixed by newer versions of the -i810 driver. Possibly this is already fixed in Gutsy (where "i810" has changed to the new "intel" driver).

[era (era)]

I shot a few pictures, they're not exactly like I'm used to seeing this, perhaps because I am now running Feisty. The grey main screen is not the X stipple pattern but will vary depending on where I move the cursor, sort of as if it was zoomed in to a single enormous pixel. The odd artefacts along the top of the screen are still there, perhaps more obvious than before.

[era (era)]

Once I cycle through the external monitor mode and back, the display is very nice, save for the funny aspect ratio (X11 doesn't use exactly the display's native mode; been too lazy to muck with that).

[era (era)]

(Sorry, dunno why xorg.conf was uploaded twice -- Launchpad glitch??)

[Bryce Harrington (bryce)]

era, great, thanks for the extra details.

Could you test one other thing - install the xserver-xorg-video-intel driver, and change your xorg.conf to use "intel" instead of "i810", and see if that makes the problem go away.

Also, if you wouldn't mind burning a CD of Ubuntu Gutsy Tribe 1 and testing that it could be a big help, since the upstream bug reports this fixed in the -intel driver we include in Gutsy.

[Launchpad Janitor (janitor)]

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

[era (era)]

I finally managed to get Gutsy to run on this machine, and indeed, the artefacts seem to be gone. Thanks!