Bug 23556 - [KMS fbdev] dysfunctional mode changing
Summary: [KMS fbdev] dysfunctional mode changing
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Dave Airlie
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2009-08-27 08:55 UTC by Kiri
Modified: 2017-07-24 23:09 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
photo of bizarre console after fbset -xres 1024 -yres 768. (423.09 KB, image/jpeg)
2010-01-21 19:43 UTC, Nick Bowler
no flags Details

Description Kiri 2009-08-27 08:55:12 UTC
This report is regarding an error with the FrameBuffer; not Xorg or Xorg in combination with the FrameBuffer.

Using linux-2.6.30.5.
Kernel Mode Setting is enabled by default through compile time setting.
INTEL_FB is disabled/uncompiled.

Hardware:
EeePC 701
http://wiki.debian.org/DebianEeePC/Model/701
$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 04)
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)

There are 2 monitors connected:
LVDS 800x480
VGA 1280x1024-75
get-edid has troubles retrieving information.

Upon boot:
the LVDS is correctly set up;
the VGA connected monitor displays the same content in the upper left hand corner.
running
links2 -driver fb
works

Upon attempting to change video mode to 1280x1024 with fbset:
the display area shrinks to a narrow left aligned column perhaps about 1/3 the previous width. White is now a visible mix of color. It seems that the R, G, & B pixels are no longer together.

The same effect happens if
links2 -driver directfb
is run.  I guess that directfb attempts to change the video mode.
Upon exiting links2, the computer responds to nothing except the Magic SysRq keys. It is appearantly locked/frozen.

I have attempted to set the 800x480 mode using fbset to see what would happen & to try and recover.  I got an error message from fbset.  I would gladly record it and post it here if desired.
Comment 1 Jesse Barnes 2009-11-20 13:01:55 UTC
There's a patch series for this at
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html

Can you give it a try and make sure it works for you?  It should be on its way upstream now.
Comment 2 Kiri 2009-11-21 03:14:00 UTC
On Friday 20 November 2009 22:01:56 you wrote:
> http://bugs.freedesktop.org/show_bug.cgi?id=23556
> 
> 
> Jesse Barnes <jbarnes@virtuousgeek.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Keywords|                            |NEEDINFO
> 
> 
> 
> 
> --- Comment #1 from Jesse Barnes <jbarnes@virtuousgeek.org>  2009-11-20 13:01:55 PST ---
> There's a patch series for this at
> http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
> 
> Can you give it a try and make sure it works for you?  It should be on its way
> upstream now.
> 
> 
> 

I am unable to compile&run kernels at the moment. When I have got it worked out, i'll give it a try.  Thanks.
Comment 3 Nick Bowler 2010-01-21 19:43:13 UTC
Created attachment 32760 [details]
photo of bizarre console after fbset -xres 1024 -yres 768.

The aforementioned patch series has been applied to the mainline kernel, but fbset is still broken.

Attempting to set a gtf-configured 1024x768 mode in /etc/fb.modes results in the following error:

  ioctl FBIOPUT_VSCREENINFO: Invalid argument

but using "fbset -xres 1024 -yres 768" causes the console size to shrink but the video mode doesn't change.  The result is extremely bizarre, attached is a photo.  I tried to take an ordinary screenshot, but this effect also happens to break fbgrab.
Comment 4 Jesse Barnes 2010-02-05 15:15:10 UTC
Since I haven't assigned any bugs to Dave recently...
Comment 5 Kiri 2010-03-04 10:15:40 UTC
I still have not compiled the kernel myself since the report.
However, I am running Linux 2.6.31-20-generic from Ubuntu and someone fixed something.
I changed the xres & yres to a few feasible values and they all worked flawlessly.
To whoever fixed it: congratulations!
Since I have not verified that the patch is in the main kernel, I have not marked it as fixed. I don't think I will be compiling in the next month, so maybe you would like to take a risk and mark as fixed anyhow.
Comment 6 Nick Bowler 2010-03-04 10:31:07 UTC
Mainline 2.6.33 is still affected by this issue.

It is not specific to i915: nouveau is affected as well.
Comment 7 Kiri 2010-03-12 00:33:31 UTC
I just looked at the screenshot attachment (id=32760).
That is not the bug I reported.
Mine behaves the same way as the screenshot, which shows that the bug I reported is fixed.
Since Mr. Bowler reports upstream behaves as shown in the screenshot, I am marking this bug as fixed.


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.