Reported-by: 屋国遥
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/radeon_atombios.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 45bc750..
2011/1/3 Pekka Paalanen :
> On Wed, 22 Dec 2010 10:51:26 +0100
> Sedat Dilek wrote:
>
>> DRIVER_DATE is not maintained or upgraded on changes in many drm
>> drivers.
>>
>> For example radeon has one DRIVER_DATE for User and Kernel
>> ModeSetting driver, this makes no sense as UMS and KMS driver
>>
for this, it can also go to /dev/nirvana.
The version related informations for drm-core seems also not to be
lovely maintained.
How long do we see 1.1.0 as version? For ages?
Did you know about interface-version?
You found the places for DRM_IF_*?
No, this is not a riddle or quiz-show, just have
On Wed, 22 Dec 2010 10:51:26 +0100
Sedat Dilek wrote:
> DRIVER_DATE is not maintained or upgraded on changes in many drm
> drivers.
>
> For example radeon has one DRIVER_DATE for User and Kernel
> ModeSetting driver, this makes no sense as UMS and KMS driver
> have different versions. And of cou
With cmwq, there's no reason for radeon to use a dedicated workqueue.
Drop dev_priv->wq and use system_wq instead.
Because radeon_driver_irq_uninstall_kms() may be called from
unsleepable context, the work items can't be flushed from there.
Instead, init and flush from radeon_irq_kms_init/fini().
With cmwq, there's no reason for nouveau to use a dedicated workqueue.
Drop dev_priv->wq and use system_wq instead.
Because nouveau_irq_uninstall() may be called from unsleepable
context, the work items can't be flushed from there. Instead, init
and flush from nouveau_load/unload().
Signed-off-b
On Wed, 22 Dec 2010 10:51:26 +0100
Sedat Dilek wrote:
> DRIVER_DATE is not maintained or upgraded on changes in many drm
> drivers.
>
> For example radeon has one DRIVER_DATE for User and Kernel
> ModeSetting driver, this makes no sense as UMS and KMS driver
> have different versions. And of cou
https://bugs.freedesktop.org/show_bug.cgi?id=32455
--- Comment #13 from Chris 2011-01-03 09:59:54 PST ---
I can confirm the game runs but doesn't output any video now, unless using
-no_vbo which avoids the VBO use.
Does this possibly mean that mame is causing the NULL vbo buffer as the first
o
https://bugs.freedesktop.org/show_bug.cgi?id=32455
--- Comment #13 from Chris 2011-01-03 09:59:54 PST ---
I can confirm the game runs but doesn't output any video now, unless using
-no_vbo which avoids the VBO use.
Does this possibly mean that mame is causing the NULL vbo buffer as the first
o
https://bugs.freedesktop.org/show_bug.cgi?id=32455
--- Comment #12 from Chris 2011-01-03 09:59:06 PST ---
Created an attachment (id=41595)
--> (https://bugs.freedesktop.org/attachment.cgi?id=41595)
OpenGL code from Mame
Client code to Mesa Gallium which triggers the no video output bug.
--
Co
https://bugs.freedesktop.org/show_bug.cgi?id=32455
--- Comment #12 from Chris 2011-01-03 09:59:06 PST ---
Created an attachment (id=41595)
--> (https://bugs.freedesktop.org/attachment.cgi?id=41595)
OpenGL code from Mame
Client code to Mesa Gallium which triggers the no video output bug.
--
Co
Hi,
On Tue, Dec 28, 2010 at 05:18:12PM -0800, ext Linus Torvalds wrote:
> Another week, another -rc. This should be the last for the 37 series,
> so I still expect the merge window to open early January when people
> are hopefully back to working order after having eaten (and drunk) too
> much.
>
Hello.
In my double-carded ASUS U30JC (nvidia + intel i915) I do the following:
stop X
This is the output of /sys/kernel/debug/vgaswitcheroo/switch
daphne linux # cat /sys/kernel/debug/vgaswitcheroo/switch
0: :Pwr::01:00.0
1:+:Pwr::00:02.0 (intel graphic card in use, ok)
echo "DDIS" >
https://bugs.freedesktop.org/show_bug.cgi?id=32789
Michel Dänzer changed:
What|Removed |Added
Product|Mesa|xorg
Version|7.9
https://bugs.freedesktop.org/show_bug.cgi?id=32789
Michel D?nzer changed:
What|Removed |Added
Product|Mesa|xorg
Version|7.9
https://bugs.freedesktop.org/show_bug.cgi?id=32789
Michel Dänzer changed:
What|Removed |Added
Attachment #41580|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=32789
Michel D?nzer changed:
What|Removed |Added
Attachment #41580|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=32789
--- Comment #1 from Maarten Maathuis 2011-01-03 06:11:26
PST ---
Landscape mode is the default rendering mode (it's called normal), anything
else causes the X server to create a new frontbuffer and render with a
transform onto this rotated front
https://bugs.freedesktop.org/show_bug.cgi?id=32789
--- Comment #1 from Maarten Maathuis 2011-01-03
06:11:26 PST ---
Landscape mode is the default rendering mode (it's called normal), anything
else causes the X server to create a new frontbuffer and render with a
transform onto this rotated front
With cmwq, there's no reason for radeon to use a dedicated workqueue.
Drop dev_priv->wq and use system_wq instead.
Because radeon_driver_irq_uninstall_kms() may be called from
unsleepable context, the work items can't be flushed from there.
Instead, init and flush from radeon_irq_kms_init/fini().
With cmwq, there's no reason for nouveau to use a dedicated workqueue.
Drop dev_priv->wq and use system_wq instead.
Because nouveau_irq_uninstall() may be called from unsleepable
context, the work items can't be flushed from there. Instead, init
and flush from nouveau_load/unload().
Signed-off-b
https://bugs.freedesktop.org/show_bug.cgi?id=32789
Summary: VSync loss after rotation to portrait mode
Product: Mesa
Version: 7.9
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priorit
Hi,
On Tue, Dec 28, 2010 at 05:18:12PM -0800, ext Linus Torvalds wrote:
> Another week, another -rc. This should be the last for the 37 series,
> so I still expect the merge window to open early January when people
> are hopefully back to working order after having eaten (and drunk) too
> much.
>
https://bugs.freedesktop.org/show_bug.cgi?id=32789
Summary: VSync loss after rotation to portrait mode
Product: Mesa
Version: 7.9
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priorit
Hello.
In my double-carded ASUS U30JC (nvidia + intel i915) I do the following:
stop X
This is the output of /sys/kernel/debug/vgaswitcheroo/switch
daphne linux # cat /sys/kernel/debug/vgaswitcheroo/switch
0: :Pwr::01:00.0
1:+:Pwr::00:02.0 (intel graphic card in use, ok)
echo "DDIS" >
25 matches
Mail list logo
