Bug 14434 - [945GM 2.2.0.90] VT consoles are shifted by one pixel
Summary: [945GM 2.2.0.90] VT consoles are shifted by one pixel
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: 7.3 (2007.09)
Hardware: Other All
: medium normal
Assignee: Jesse Barnes
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 13493
  Show dependency treegraph
 
Reported: 2008-02-08 15:39 UTC by Guillaume Melquiond
Modified: 2008-02-21 08:39 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Log file with mode debug (64.29 KB, text/x-log)
2008-02-08 15:39 UTC, Guillaume Melquiond
no flags Details
Switch ARX back to index mode (339 bytes, patch)
2008-02-19 13:03 UTC, Jesse Barnes
no flags Details | Splinter Review

Description Guillaume Melquiond 2008-02-08 15:39:36 UTC
Created attachment 14226 [details]
Log file with mode debug

This bug happens with Intel driver 2.2.0.90 on a 945 graphic chip. After the boot, once X has started, VT text consoles are messed. The pixels of the first column are displayed on the right of the display (as if the start address of the display buffer was off by one byte, but I'm not sure there is anything like that for text modes). These consoles are pure text, I don't use the framebuffer for them. This is a regression with respect to version 2.2.0.
Comment 1 Wang Zhenyu 2008-02-11 07:03:53 UTC
Could you help to git bisect which commit causes the problem you see?
Comment 2 Guillaume Melquiond 2008-02-11 08:32:36 UTC
I can git bisect, but unfortunately not before next Saturday. So please wait for a week.

As an additional detail to my report, note that the leftmost pixels (the ones wrongly displayed on the right of the screen) are vertically shifted by a whole character height and not by a single pixel. This kind of makes sense since this is happening in text mode. (But the fact that only the leftmost pixels, and not the leftmost whole characters, are messed, does not make any sense to me.)
Comment 3 Guillaume Melquiond 2008-02-16 03:19:41 UTC
I was mistaken. After wasting several hours on recompiling/rebooting with various versions, I have been able to reproduce the bug with 2.2.0 too. So it is not a regression, or at least not with respect to 2.2.0.

Here is a summary of my experiments in reproducing the bug:

- set modedebug to off
- reboot the computer
- start X
  -> VTs are fine
- set modedebug to on
- start X
  -> VTs are fine
- reboot the computer
- start X
  -> VTs are messed

In other words, if the first X started after the boot has no modedebug, then everything is fine, the issue never occurs. But if the first X started after the boot has modedebug, then VTs are broken until next reboot.

So I looked a bit at the code and I noticed a place where modedebug changes the control flow of the driver. I am not saying that this is related to this specific bug, but it nonetheless looks like a bug: At line i830_lvds.c:983, the bios mode of the LVDS display is freed only when modedebug is enabled. So it means that, either there is a double free in debug mode, or there is a memory leak in non debug mode.
Comment 4 Jesse Barnes 2008-02-16 10:54:42 UTC
It may also be that the modedebug VGA code leaves the ARX register in data mode, rather than index mode, I'll take a look.
Comment 5 Jesse Barnes 2008-02-19 13:03:35 UTC
Created attachment 14426 [details] [review]
Switch ARX back to index mode

Can you give this patch a try?  It should switch the ARX register back to index mode from data mode, hopefully preventing the AR corruption you're seeing.
Comment 6 Guillaume Melquiond 2008-02-20 23:52:16 UTC
The patch fixes the issue. Thanks.
Comment 7 Jesse Barnes 2008-02-21 08:39:40 UTC
Thanks for testing.  Fixed in 444984a578aae92ff55c06da897ea1d23679e706.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.