2.6.34-rc6-git2: Reported regressions from 2.6.33

2010-05-04 Thread Rafael J. Wysocki
This message contains a list of some regressions from 2.6.33, for which there are no fixes in the mainline known to the tracking team. If any of them have been fixed already, please let us know. If you know of any other unresolved regressions from 2.6.33, please let us know either and we'll add

[Bug 15166] Changing brightness of backlight freezes kernel with radeon kms enabled.

2010-05-04 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=15166 --- Comment #47 from Aurélien Couderc zecou...@free.fr 2010-05-04 22:59:41 --- Yes, it's fixed in drm-radeon-testing for my laptop too. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving

Re: 2.6.34-rc6-git2: Reported regressions from 2.6.33

2010-05-04 Thread Linus Torvalds
On Tue, 4 May 2010, Rafael J. Wysocki wrote: Unresolved regressions -- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15880 Subject : Very bad regression from 2.6.33 as of 1600f9def Submitter : Alex Elsayed eternal...@gmail.com Date

[PATCH 1/3] drm/radeon/kms: avoid executing dac detection table on r4xx + rv515.

2010-05-04 Thread Dave Airlie
From: Dave Airlie airl...@redhat.com The DAC Load detection table is meant to take a parameter selecting the DAC to do load detection on. However on certain BIOS revisions it accept no parameters and load detects both DACs, with the result that load detecting on the second DAC causes flicker on

RFC: output polling + disconnected operation

2010-05-04 Thread Dave Airlie
So one of the problems I want to solve for KMS it the what to do when nothing is plugged in at startup, I've fixed this for fbcon in the current tree, but when looking at X + randr clients I realised it needed a bit more work. I've pulled the polling code back into the core, and it nows can

[PATCH 2/2] drm: create fake disconnected connector for use when nothing is plugged in.

2010-05-04 Thread Dave Airlie
From: Dave Airlie airl...@redhat.com The problem with using a real connector with a fake status is we have no way to tell userspace it got disconnected if something gets plugged into it, i.e. you use DVI-0 as the connector with an unknown or connected status, and it puts a 1024x768 mode on it.

[PATCH 1/2] drm/fbdev: rework output polling to be back in the core.

2010-05-04 Thread Dave Airlie
From: Dave Airlie airl...@redhat.com After thinking it over a lot it made more sense for the core to deal with the output polling especially so it can notify X. Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/gpu/drm/Kconfig|2 +-

Re: RFC: output polling + disconnected operation

2010-05-04 Thread Dave Airlie
On Wed, May 5, 2010 at 11:37 AM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed,  5 May 2010 11:12:13 +1000 Dave Airlie airl...@gmail.com wrote: So at startup X drivers genearlly seem to ask for a list of connectors and status for them, and if it can't find any connected, it goes to

Re: RFC: output polling + disconnected operation

2010-05-04 Thread Jesse Barnes
On Wed, 5 May 2010 11:12:13 +1000 Dave Airlie airl...@gmail.com wrote: So at startup X drivers genearlly seem to ask for a list of connectors and status for them, and if it can't find any connected, it goes to unknown, and if none of those they fall over and X exits. Idea 1 was to just pick a