Hi List,
I've an device with an Intel GMA/Poulsbo chip, PCI ID 8080:8101.
Under (self-compiled) Linux 3.2.31 I've used psb_gfx, now with 3.8.10 I'm using gma500_gfx.
But now the display under X11 (xserver-xorg-video-fbdev from Debian, 1:0.4.2-4+b2) shows the image moved some lines up on the newer kernel. I'd guess that the first 4 to 6 lines are missing. I've run both kernels with drm.debug=0x04, but haven't found something that looked suspicious. Or, well, maybe not. The output of drm_mode_debug_printmodeline is a bit different, 0x0 vs. 0xa.
/var/log/Xorg.0.log doesn't contain anything differiing at all that is related to video output.
And hints on how I could pursue this issue?
3.2.31, "dmesg | grep drm":
Kernel command line: BOOT_IMAGE=/boot/vmlinuz root=/dev/sda1 ro quiet init=/bin/systemd video=LVDS-1:800x600 drm.debug=0x04 [drm] Initialized drm 1.1.0 20060810 [drm:drm_mode_debug_printmodeline], Modeline 0:"800x600" 0 39790 800 824 896 1056 600 601 603 628 0x8 0x0 [drm] SGX core id = 0x01130000 [drm] SGX core rev major = 0x01, minor = 0x02 [drm] SGX core rev maintenance = 0x01, designer = 0x00 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] No driver support for vblank timestamp query. [drm:drm_fb_helper_parse_command_line], cmdline mode for connector LVDS-1 800x600@60Hz [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:7:LVDS-1] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:7:LVDS-1] probed modes : [drm:drm_mode_debug_printmodeline], Modeline 20:"800x600" 60 39790 800 824 896 1056 600 601 603 628 0x48 0xa [drm:drm_mode_debug_printmodeline], Modeline 28:"800x600" 72 50000 800 856 976 1040 600 637 643 666 0x40 0x5 [drm:drm_mode_debug_printmodeline], Modeline 27:"800x600" 75 49500 800 816 896 1056 600 601 604 625 0x40 0x5 [drm:drm_mode_debug_printmodeline], Modeline 21:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5 [drm:drm_mode_debug_printmodeline], Modeline 22:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5 [drm:drm_mode_debug_printmodeline], Modeline 24:"640x480" 73 31500 640 664 704 832 480 489 491 520 0x40 0xa [drm:drm_mode_debug_printmodeline], Modeline 23:"640x480" 75 31500 640 656 720 840 480 481 484 500 0x40 0xa [drm:drm_mode_debug_printmodeline], Modeline 25:"640x480" 60 25200 640 656 752 800 480 490 492 525 0x40 0xa [drm:drm_mode_debug_printmodeline], Modeline 26:"720x400" 70 28320 720 738 846 900 400 412 414 449 0x40 0x6 [drm:drm_setup_crtcs], [drm:drm_enable_connectors], connector 7 enabled? yes [drm:drm_target_preferred], looking for cmdline mode on connector 7 [drm:drm_target_preferred], found mode 800x600 [drm:drm_setup_crtcs], picking CRTCs for 2048x2048 config [drm:drm_setup_crtcs], desired mode 800x600 set on crtc 4 [drm:drm_crtc_helper_set_config], [drm:drm_crtc_helper_set_config], [CRTC:3] [NOFB] [drm:drm_crtc_helper_set_config], [drm:drm_crtc_helper_set_config], [CRTC:4] [FB:11] #connectors=1 (x y) (0 0) [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set [drm:drm_crtc_helper_set_config], modes are different, full mode set [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0 [drm:drm_mode_debug_printmodeline], Modeline 10:"800x600" 60 39790 800 824 896 1056 600 601 603 628 0x48 0xa [drm:drm_crtc_helper_set_config], encoder changed, full mode switch [drm:drm_crtc_helper_set_config], crtc changed, full mode switch [drm:drm_crtc_helper_set_config], [CONNECTOR:7:LVDS-1] to [CRTC:4] [drm:drm_crtc_helper_set_config], attempting to set mode from userspace [drm:drm_mode_debug_printmodeline], Modeline 10:"800x600" 60 39790 800 824 896 1056 600 601 603 628 0x48 0xa [drm:drm_crtc_helper_set_mode], [CRTC:4] [drm:drm_mode_debug_printmodeline], Modeline 10:"800x600" 60 39790 800 824 896 1056 600 601 603 628 0x48 0xa [drm:drm_crtc_helper_set_mode], [ENCODER:8:LVDS-8] set [MODE:10:800x600] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [drm:drm_crtc_helper_set_config], [CONNECTOR:7:LVDS-1] set DPMS on drm: registered panic notifier [drm] Initialized gma500 1.0.0 2011-06-06 for 0000:00:02.0 on minor 0
3.8.10, "dmesg | grep drm":
Kernel command line: BOOT_IMAGE=/boot/vmlinuz root=/dev/sda1 ro quiet init=/bin/systemd video=LVDS-1:800x600 drm.debug=0x04 [drm] Initialized drm 1.1.0 20060810 [drm:psb_intel_init_bios], Using VBT from OpRegion: $VBT POULSBO d [drm:drm_mode_debug_printmodeline], Modeline 0:"800x600" 0 39790 800 824 896 1056 600 601 603 628 0x8 0xa [drm:parse_sdvo_device_mapping], No SDVO device info is found in VBT [drm:parse_edp], EDP timing in vbt t1_t3 32810 t8 162 t9 34014 t10 0 t11_t12 6144 [drm:parse_edp], VBT reports EDP: Lane_count 1, Lane_rate 6, Bpp 18 [drm:parse_edp], VBT reports EDP: VSwing 0, Preemph 0 [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] No driver support for vblank timestamp query. [drm:psb_intel_sdvo_read_byte], i2c transfer returned -6 [drm:psb_intel_sdvo_init], No SDVO device found on SDVOB [drm:drm_fb_helper_parse_command_line], cmdline mode for connector LVDS-1 800x600@60Hz [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:7:LVDS-1] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter intel drm LVDSBLC_B [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:7:LVDS-1] probed modes : [drm:drm_mode_debug_printmodeline], Modeline 20:"800x600" 60 39790 800 824 896 1056 600 601 603 628 0x48 0xa [drm:drm_mode_debug_printmodeline], Modeline 18:"800x600" 72 50000 800 856 976 1040 600 637 643 666 0x40 0x5 [drm:drm_mode_debug_printmodeline], Modeline 17:"800x600" 75 49500 800 816 896 1056 600 601 604 625 0x40 0x5 [drm:drm_mode_debug_printmodeline], Modeline 11:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5 [drm:drm_mode_debug_printmodeline], Modeline 12:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5 [drm:drm_mode_debug_printmodeline], Modeline 14:"640x480" 73 31500 640 664 704 832 480 489 491 520 0x40 0xa [drm:drm_mode_debug_printmodeline], Modeline 13:"640x480" 75 31500 640 656 720 840 480 481 484 500 0x40 0xa [drm:drm_mode_debug_printmodeline], Modeline 15:"640x480" 60 25200 640 656 752 800 480 490 492 525 0x40 0xa [drm:drm_mode_debug_printmodeline], Modeline 16:"720x400" 70 28320 720 738 846 900 400 412 414 449 0x40 0x6 [drm:drm_setup_crtcs], [drm:drm_enable_connectors], connector 7 enabled? yes [drm:drm_target_preferred], looking for cmdline mode on connector 7 [drm:drm_target_preferred], found mode 800x600 [drm:drm_setup_crtcs], picking CRTCs for 2048x2048 config [drm:drm_setup_crtcs], desired mode 800x600 set on crtc 4 [drm:drm_crtc_helper_set_config], [drm:drm_crtc_helper_set_config], [CRTC:3] [NOFB] [drm:drm_crtc_helper_set_config], [drm:drm_crtc_helper_set_config], [CRTC:4] [FB:21] #connectors=1 (x y) (0 0) [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set [drm:drm_crtc_helper_set_config], modes are different, full mode set [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0 [drm:drm_mode_debug_printmodeline], Modeline 10:"800x600" 60 39790 800 824 896 1056 600 601 603 628 0x48 0xa [drm:drm_crtc_helper_set_config], encoder changed, full mode switch [drm:drm_crtc_helper_set_config], crtc changed, full mode switch [drm:drm_crtc_helper_set_config], [CONNECTOR:7:LVDS-1] to [CRTC:4] [drm:drm_crtc_helper_set_config], attempting to set mode from userspace [drm:drm_mode_debug_printmodeline], Modeline 10:"800x600" 60 39790 800 824 896 1056 600 601 603 628 0x48 0xa [drm:drm_crtc_helper_set_mode], [CRTC:4] [drm:drm_mode_debug_printmodeline], Modeline 10:"800x600" 60 39790 800 824 896 1056 600 601 603 628 0x48 0xa [drm:drm_crtc_helper_set_mode], [ENCODER:8:LVDS-8] set [MODE:10:800x600] [drm:drm_crtc_helper_set_config], Setting connector DPMS state to on [drm:drm_crtc_helper_set_config], [CONNECTOR:7:LVDS-1] set DPMS on [drm] Initialized gma500 1.0.0 2011-06-06 for 0000:00:02.0 on minor 0
/var/log/Xorg.0.log doesn't contain anything differiing at all that is related to video output.
And hints on how I could pursue this issue?
Try installing xf86-video-modesetting driver or whatever your distro calls it.
Dave.
Thanks Dave, for the fast answer.
I had a new attack of a "BWAAAH, since 5 years graphics drivers for X11 on Linux are a mess" moment. Things don't work out of the box, and if you try google-fu, then you get ton's of ancient, outdated or only halfways true information. Grrr.
That's not downplaying your work or knowledge at all, Dave. It's just an outburst of a feeling!
I installed xserver-xorg-video-modesettings (from Debian Wheezy) and also updated xserver-core, -evdev, -vesa and -fbdev. The I started X11. Seems that Debian doesn't yet contain the addition of the modesettings driver to the auto-probed drivers, Xorg.0.log didn't contain a trace of modesettings.
So I added
Section "Device" Identifier "gma" Driver "modesetting" BusID "pci:0:2:0 EndSection
But then I get
[ 4309.430] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 4309.430] (--) using VT number 1
[ 4309.463] (WW) Falling back to old probe method for modesetting [ 4309.464] (II) UnloadModule: "modesetting" [ 4309.464] (EE) Screen(s) found, but none have a usable configuration. [ 4309.464] Fatal server error: [ 4309.464] no screens found
So, I tried to add a screen, while grumbling "Since when do I need a 'Screen' section in a modern xorg.conf again?":
Section "Screen" Identifier "800x600" Device "Card0" DefaultDepth 24 EndSection
But X11 still says
[ 4440.511] (EE) Screen(s) found, but none have a usable configuration. [ 4440.511] Fatal server error: [ 4440.511] no screens found
And of course, it's silent about WHAT exactly would constitute a usable configuration.
I tried 32 bits depth as well. I tried adding a subsection "Display". I tried to stay calm ... but no success so far! :-)
BTW, I upgraded to kernel 3.9.2 for this.
2013/5/13 Dave Airlie airlied@gmail.com
/var/log/Xorg.0.log doesn't contain anything differiing at all that is related to video output.
And hints on how I could pursue this issue?
Try installing xf86-video-modesetting driver or whatever your distro calls it.
Dave.
On Mon, May 13, 2013 at 3:02 PM, Holger Schurig holgerschurig@gmail.com wrote:
I installed xserver-xorg-video-modesettings (from Debian Wheezy) and also updated xserver-core, -evdev, -vesa and -fbdev. The I started X11. Seems that Debian doesn't yet contain the addition of the modesettings driver to the auto-probed drivers, Xorg.0.log didn't contain a trace of modesettings.
So I added
Section "Device" Identifier "gma" Driver "modesetting" BusID "pci:0:2:0 EndSection
But then I get
[ 4309.430] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 4309.430] (--) using VT number 1
[ 4309.463] (WW) Falling back to old probe method for modesetting [ 4309.464] (II) UnloadModule: "modesetting" [ 4309.464] (EE) Screen(s) found, but none have a usable configuration. [ 4309.464] Fatal server error: [ 4309.464] no screens found
So, I tried to add a screen, while grumbling "Since when do I need a 'Screen' section in a modern xorg.conf again?":
Section "Screen" Identifier "800x600" Device "Card0" DefaultDepth 24 EndSection
But X11 still says
[ 4440.511] (EE) Screen(s) found, but none have a usable configuration. [ 4440.511] Fatal server error: [ 4440.511] no screens found
And of course, it's silent about WHAT exactly would constitute a usable configuration.
I tried 32 bits depth as well. I tried adding a subsection "Display". I tried to stay calm ... but no success so far! :-)
BTW, I upgraded to kernel 3.9.2 for this.
Hi
Valid device id's for poulsbo are 8086:8108 and 8086:8109 so 8080:8101 is something else.
You should be fine with just:
Section "Device" Identifier "gma" Driver "modesetting" EndSection
So there is something else going on. Can we get a full dmesg on 3.9.2 with drm.debug=0xf
Thanks Patrik
Oops, I did mistype. I have an 8086:8108:
# lspci --n | head -n 2 00:00.0 Host bridge [0600]: Intel Corporation System Controller Hub (SCH Poulsbo) [8086:8100] (rev 07) 00:02.0 VGA compatible controller [0300]: Intel Corporation System Controller Hub (SCH Poulsbo) Graphics Controller [8086:8108] (rev 07)
Somehow I think that this is a kernel regression, because for Kernel 3.2.31 I've used xorg-server-video-fbdev and psb_gfx, and there it worked correctly.
Unfortunately my kernel has around 32 quilt patches added (e.g. aufs3), so it's not easy for me to do a bi-section.
2013/5/13 Patrik Jakobsson patrik.r.jakobsson@gmail.com:
On Mon, May 13, 2013 at 3:02 PM, Holger Schurig holgerschurig@gmail.com wrote:
I installed xserver-xorg-video-modesettings (from Debian Wheezy) and also updated xserver-core, -evdev, -vesa and -fbdev. The I started X11. Seems that Debian doesn't yet contain the addition of the modesettings driver to the auto-probed drivers, Xorg.0.log didn't contain a trace of modesettings.
So I added
Section "Device" Identifier "gma" Driver "modesetting" BusID "pci:0:2:0 EndSection
But then I get
[ 4309.430] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 4309.430] (--) using VT number 1
[ 4309.463] (WW) Falling back to old probe method for modesetting [ 4309.464] (II) UnloadModule: "modesetting" [ 4309.464] (EE) Screen(s) found, but none have a usable configuration. [ 4309.464] Fatal server error: [ 4309.464] no screens found
So, I tried to add a screen, while grumbling "Since when do I need a 'Screen' section in a modern xorg.conf again?":
Section "Screen" Identifier "800x600" Device "Card0" DefaultDepth 24 EndSection
But X11 still says
[ 4440.511] (EE) Screen(s) found, but none have a usable configuration. [ 4440.511] Fatal server error: [ 4440.511] no screens found
And of course, it's silent about WHAT exactly would constitute a usable configuration.
I tried 32 bits depth as well. I tried adding a subsection "Display". I tried to stay calm ... but no success so far! :-)
BTW, I upgraded to kernel 3.9.2 for this.
Hi
Valid device id's for poulsbo are 8086:8108 and 8086:8109 so 8080:8101 is something else.
You should be fine with just:
Section "Device" Identifier "gma" Driver "modesetting" EndSection
So there is something else going on. Can we get a full dmesg on 3.9.2 with drm.debug=0xf
Thanks Patrik
Okay, I've can now circle the problem out. What did I do:
* I used vanilla-3.9.2 kernel, but brougth drivers/gpu/drm/gma500 to the state of Linus' git tree commit id 0cdbee3e811b1bbb347c61814c8570658f2ab15c. This was shortly after gma500 moved out of staging * then I did "git format-patch 0cdbee3e811b1bbb347c61814c8570658f2ab15c..master drivers/gpu/drm/gma500/" * I then took the following patches to get this antique gma500 driver compile against kernel 3.9.2 with it's updated DRM: ** psb/0001-drm-gma500-fix-compile-error.patch ** psb/0002-drm-move-the-fb-bpp-depth-helper-into-the-core.patch ** psb/0020-drm-Replace-pitch-with-pitches-in-drm_framebuffer.patch ** psb/0095-gma500-remove-the-second-argument-of-k-un-map_atomic.patch ** psb/0151-drm-Make-the-.mode_fixup-operations-mode-argument-a-.patch (modified) ** psb/0152-drm-kill-reclaim_buffers-callback.patch ** psb/0175-mm-kill-vma-flag-VM_RESERVED-and-mm-reserved_vm-coun.patch ** psb/0178-drm-gma500-drm_connector_property-drm_object_propert.patch (modified)
Now this franken-gma500_gfx driver runs perfectly with xserver-xorg-video-fbdev and doesn't have the displaced vertical screen issue.
Now I can roll in other patches until I find the culprit.
Okay, I found the patch that produces my regression:
----------------------------------------------------------------------------
From bc794829141f28e14fe7d0e07e35870bd9aee78c Mon Sep 17 00:00:00 2001
From: Patrik Jakobsson patrik.r.jakobsson@gmail.com Date: Mon, 21 May 2012 15:27:30 +0100 Subject: [PATCH 143/209] gma500: handle poulsbo cursor restriction
Poulsbo needs a physical address in the cursor base register. We allocate a stolen memory buffer and copy the cursor image provided by userspace into it. When/If we get our own userspace driver we can map this stolen memory directly. The patch also adds a mark in chip ops so we can identify devices that has this requirement. ----------------------------------------------------------------------------
When I modify the patch that psb_chip_ops.cursor_needs_phys doesn't get initialized to 1, then the display doesn't get displaced.
On Tue, May 14, 2013 at 2:13 PM, Holger Schurig holgerschurig@gmail.com wrote:
Okay, I found the patch that produces my regression:
From bc794829141f28e14fe7d0e07e35870bd9aee78c Mon Sep 17 00:00:00 2001 From: Patrik Jakobsson patrik.r.jakobsson@gmail.com Date: Mon, 21 May 2012 15:27:30 +0100 Subject: [PATCH 143/209] gma500: handle poulsbo cursor restriction
Poulsbo needs a physical address in the cursor base register. We allocate a stolen memory buffer and copy the cursor image provided by userspace into it. When/If we get our own userspace driver we can map this stolen memory directly. The patch also adds a mark in chip ops so we can identify devices that has this requirement.
When I modify the patch that psb_chip_ops.cursor_needs_phys doesn't get initialized to 1, then the display doesn't get displaced.
Hmm, I would have guessed on the gtt rolling code, but this makes sense.
If we need phys cursor, we allocate a cursor bo in stolen memory and this happens before the framebuffer is allocated, thus moving the framebuffer 4 pages. Since the gtt rolling code tries to put a pitch of 1 page so it can perform it's trick we loose 4 lines at the top. The actual problem is in psbfb_vm_fault() where we assume the framebuffer to be at the start of stolen memory. The following patch should fix your problem, though I recommend you use the modesetting driver because you get a hardware accelerated cursor.
Thanks Patrik
From 1d68e97f39cb70862f7b02bb430e64dfa07fd08d Mon Sep 17 00:00:00 2001
From: Patrik Jakobsson patrik.r.jakobsson@gmail.com Date: Tue, 14 May 2013 14:37:10 +0200 Subject: [PATCH] drm/gma500: Add fb gtt offset to fb base
Old code assumed framebuffer starts at base of stolen memory. Since the addition of hardware cursors, this might not be true anymore so add the gtt offset to the calculation.
Reported-by: Holger Schurig holgerschurig@gmail.com Signed-off-by: Patrik Jakobsson patrik.r.jakobsson@gmail.com --- drivers/gpu/drm/gma500/framebuffer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/framebuffer.c b/drivers/gpu/drm/gma500/framebuffer.c index 1534e22..8b1b6d9 100644 --- a/drivers/gpu/drm/gma500/framebuffer.c +++ b/drivers/gpu/drm/gma500/framebuffer.c @@ -121,8 +121,8 @@ static int psbfb_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf) unsigned long address; int ret; unsigned long pfn; - /* FIXME: assumes fb at stolen base which may not be true */ - unsigned long phys_addr = (unsigned long)dev_priv->stolen_base; + unsigned long phys_addr = (unsigned long)dev_priv->stolen_base + + psbfb->gtt->offset;
page_num = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT; address = (unsigned long)vmf->virtual_address - (vmf->pgoff << PAGE_SHIFT);
Patrick, have a
Tested-by: Holger Schurig holgerschurig@gmail.com
for this.
As for your suggestion:
though I recommend you use the modesetting driver because you get a hardware accelerated cursor.
The current Debian Wheezy xserver-xorg doesn't autoload the modesettings X11 driver. And I haven't found out how to manually load that driver ... also, there is about zilch documentation on that driver available, also the error messages in the Xorg.0.log don't help in any way. So, all in all this is too much hassle.
So I'll wait until support for that comes in up Debian SID a.k.a. Unstable. I actually don't care about an "accelerated cursor" at all. I don't perceive the mouse cursor (or the text cursor in rxvt-unicode) to be "slow", so there's not much reason (for me!) in accellerating it in the first place.
On Tue, May 14, 2013 at 3:07 PM, Holger Schurig holgerschurig@gmail.com wrote:
Patrick, have a
Tested-by: Holger Schurig holgerschurig@gmail.com
for this.
I'll add that.
As for your suggestion:
though I recommend you use the modesetting driver because you get a hardware accelerated cursor.
The current Debian Wheezy xserver-xorg doesn't autoload the modesettings X11 driver. And I haven't found out how to manually load that driver ... also, there is about zilch documentation on that driver available, also the error messages in the Xorg.0.log don't help in any way. So, all in all this is too much hassle.
That still confuses me, but let's hope it automagically goes away some day.
So I'll wait until support for that comes in up Debian SID a.k.a. Unstable. I actually don't care about an "accelerated cursor" at all. I don't perceive the mouse cursor (or the text cursor in rxvt-unicode) to be "slow", so there's not much reason (for me!) in accellerating it in the first place.
Sure, you'll only see a difference if you're running a compositing window manager or your system is under heavy load.
-Patrik
On Mon, 13 May 2013 15:02:46 +0200, Holger Schurig holgerschurig@gmail.com wrote :
Thanks Dave, for the fast answer.
I had a new attack of a "BWAAAH, since 5 years graphics drivers for X11 on Linux are a mess" moment. Things don't work out of the box, and if you try google-fu, then you get ton's of ancient, outdated or only halfways true information. Grrr.
That's not downplaying your work or knowledge at all, Dave. It's just an outburst of a feeling!
I installed xserver-xorg-video-modesettings (from Debian Wheezy) and also
The wheezy driver is too old, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683526
So no wonder it doesn't work. You can try applying the patches manually or just compiling a more recent version of xf86-video-modesetting. Make yourself known on this debian bug if it fixes it for you.
Regards,
Anisse
Thanks, Anisse, but Dave's answer was wrong anyway. Using a different user-space-driver wouldn't have magically fixed the bug in the kernel KMS driver part.
Eventually something newer will pop up in Debian SID and/or Debian Backports. I'll then pick it. As the performance of the device doesn't bother me, I see no need. The more I stay at what Debian provides, the less I have to maintain by myself :-)
dri-devel@lists.freedesktop.org
-
Anisse Astier -
Dave Airlie -
Holger Schurig -
Patrik Jakobsson