Bug 23556

Summary:

[KMS fbdev] dysfunctional mode changing

Product:

DRI

Reporter:

Kiri <hohyeis>

Component:

DRM/Intel

Assignee:

Dave Airlie <airlied>

Status:

CLOSED FIXED

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

medium

CC:

nbowler

Version:

unspecified

Keywords:

NEEDINFO

Hardware:

x86 (IA32)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
photo of bizarre console after fbset -xres 1024 -yres 768.	none

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.