Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #963283 > unrolled thread

Bug#931430: Acknowledgement (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#931430: Acknowledgement (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet) userm57@yahoo.com - 2019-07-04 21:10 +0200
    Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet) Finn Thain <fthain@telegraphics.com.au> - 2019-07-12 03:10 +0200
      Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet) userm57@yahoo.com - 2019-07-12 03:40 +0200
        Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet) Finn Thain <fthain@telegraphics.com.au> - 2019-07-12 04:20 +0200
          Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet) userm57@yahoo.com - 2019-07-12 04:50 +0200
            Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet) Finn Thain <fthain@telegraphics.com.au> - 2019-07-12 12:10 +0200
    Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet) Michel Dänzer <michel@daenzer.net> - 2019-07-12 10:10 +0200
      Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet) Finn Thain <fthain@telegraphics.com.au> - 2019-07-12 12:10 +0200
        Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet) Michel Dänzer <michel@daenzer.net> - 2019-07-12 12:20 +0200
    Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet) Finn Thain <fthain@telegraphics.com.au> - 2019-07-13 02:30 +0200
      Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet) Michel Dänzer <michel@daenzer.net> - 2019-07-15 11:50 +0200
        Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet) Finn Thain <fthain@telegraphics.com.au> - 2019-07-15 13:00 +0200

#963283 — Bug#931430: Acknowledgement (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

Correction: The CPU of the Wallstreet is 266 MHz, not 292 MHz.

On 7/4/19 1:00 PM, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
> 
> You can follow progress on this Bug here: 931430: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931430.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Debian X Strike Force <debian-x@lists.debian.org>
> 
> If you wish to submit further information on this problem, please
> send it to 931430@bugs.debian.org.
> 
> Please do not send mail to owner@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
> 

[toc] | [next] | [standalone]

#964221 — Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

On Thu, 11 Jul 2019, userm57@yahoo.com wrote:

> 8) Xorg_sid_fbdev.log    : Xorg log file for test (3)
> 9) Xorg_sid_mach64.log   : Xorg log file for test (4)

Thanks for sending these results.

Unfortunately these SID test results might be skewed because the X server 
is continually logging "dbus-core: error connecting to system bus" at 10 
times per second. So if you're using single-user mode, you may have to 
start up dbus first.

Anyway, if we assume that the measurements aren't skewed, we see that the 
majority of the the x11perf measurements have regressed (for fbdev).

But note that, unlike mach64, fbdev performance depends on both the kernel 
fbdev driver and the x server fbdev driver. These test results were taken 
from different kernels.

When you make fbdev measurements, you should use the same kernel binary 
and kernel parameters for each test. In the previous fbdev test, I think 
you used a kernel that I built from Debian's .config --

[   236.387] Current Operating System: Linux mac-server 4.19.56-debian-pmac #1 Wed Jul 3 20:08:58 AEST 2019 ppc
[   236.387] Kernel command line: root=/dev/sda11 single ignore_loglevel printk.time console=ttyS0,9600n8 video=ofonly

I think this was a good choice.

Please also capture the complete console log if convenient.

> 
> c) The glxgears tests are included for reference.  Those results give a 
> better picture of the overall slowdown in X11 graphics from Debian 8.11 
> to Debian sid.  The slowdown is most easily seen when running in 
> multiuser mode with Xfce (see particularly the last two tests in the 
> file), where the glxgears FPS is about 14.1 FPS in Debian 8.11 but only 
> 4.7 FPS in Debian sid.  So perhaps there are some interrelated issues 
> with Xorg and Xfce and/or mesa-utils, especially since glxgears has 
> intermittent segmentation and illegal instruction errors (only in sid).
> 

Unfortunately, glxgears doesn't reflect the "overall slowdown". More data 
is always good, however, the x11perf microbenchmarks are more tightly 
focused.

> d) It takes approximately three seconds to open an xfce4-terminal in
> Debian 8.11, six seconds in Debian sid.
> 

A 50% slowdown is serious. But it may not be caused by Xorg.

If you were to patch the X server, or change the xorg.conf (e.g. shadowfb) 
or downgrade all of the X server packages, and if this fixed the slowdown, 
then that would prove that the regression was in the X server.

But it seems that you already have x11perf results which demonstrate an X 
server performance regression. Fixing this may or may not fix the Xfce 
slowdown. It remains to be seen.

> e) Moving and resizing windows might be faster in all versions of Debian 
> if the default setting would be to highlight only the window borders 
> while moving or resizing, instead of including the window contents. This 
> is probably an Xfce setting.
> 

Right. If Xfce doesn't offer this feature, there are certainly other 
window managers that do offer this.

If this is an Xfce bug, you'll need to file a bug report against that 
package, in order to reach the relevant developers.

-- 

> -Stan Johnson
>  userm57@yahoo.com
> 

[toc] | [prev] | [next] | [standalone]

#964224 — Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

On 7/11/19 6:57 PM, Finn Thain wrote:
> 
> On Thu, 11 Jul 2019, userm57@yahoo.com wrote:
> 
>> 8) Xorg_sid_fbdev.log    : Xorg log file for test (3)
>> 9) Xorg_sid_mach64.log   : Xorg log file for test (4)
> 
> Thanks for sending these results.
> 
> Unfortunately these SID test results might be skewed because the X server 
> is continually logging "dbus-core: error connecting to system bus" at 10 
> times per second. So if you're using single-user mode, you may have to 
> start up dbus first.

Yeah, I noticed those dbus errors.  Instead of just starting dbus from
single-user, it would be easier to start multiuser, then kill wdm and
restart X from the serial console using xinit.  I can run those two
tests tomorrow (repeating tests 8 and 9 above).  And I'll capture the
console log for those tests.

> 
> Anyway, if we assume that the measurements aren't skewed, we see that the 
> majority of the the x11perf measurements have regressed (for fbdev).
> 
> But note that, unlike mach64, fbdev performance depends on both the kernel 
> fbdev driver and the x server fbdev driver. These test results were taken 
> from different kernels.

No, for all the tests today, I used 4.19.56-debian-pmac, with the same
kernel command line (except for root=).

> 
> When you make fbdev measurements, you should use the same kernel binary 
> and kernel parameters for each test. In the previous fbdev test, I think 
> you used a kernel that I built from Debian's .config --
> 
> [   236.387] Current Operating System: Linux mac-server 4.19.56-debian-pmac #1 Wed Jul 3 20:08:58 AEST 2019 ppc
> [   236.387] Kernel command line: root=/dev/sda11 single ignore_loglevel printk.time console=ttyS0,9600n8 video=ofonly
> 
> I think this was a good choice.
> 
> Please also capture the complete console log if convenient.
> 
>>
>> c) The glxgears tests are included for reference.  Those results give a 
>> better picture of the overall slowdown in X11 graphics from Debian 8.11 
>> to Debian sid.  The slowdown is most easily seen when running in 
>> multiuser mode with Xfce (see particularly the last two tests in the 
>> file), where the glxgears FPS is about 14.1 FPS in Debian 8.11 but only 
>> 4.7 FPS in Debian sid.  So perhaps there are some interrelated issues 
>> with Xorg and Xfce and/or mesa-utils, especially since glxgears has 
>> intermittent segmentation and illegal instruction errors (only in sid).
>>
> 
> Unfortunately, glxgears doesn't reflect the "overall slowdown". 

Well, glxgears accurately represents the slowness that I perceive on the
Desktop going from Debian 7.8 to 8.11 to sid.  It's probably also
important that the startup time (first FPS) for glxgears is much lower
in sid, and of course the segmentation and illegal instruction errors
are probably important as well (but those may be an issue with
mesa-utils, or possibly related to the dbus issue).

> More data 
> is always good, however, the x11perf microbenchmarks are more tightly 
> focused.
> 
>> d) It takes approximately three seconds to open an xfce4-terminal in
>> Debian 8.11, six seconds in Debian sid.
>>
> 
> A 50% slowdown is serious. But it may not be caused by Xorg.

Right.  The 50% slowdown could just as easily be caused by Xfce, fvwm,
or even xfce-terminal.

> 
> If you were to patch the X server, or change the xorg.conf (e.g. shadowfb) 

Shadowfb has no effect for mach64.  I didn't test it for fbdev.  For
these tests, I didn't use shadowfb, or any custom xorg.conf files.

> or downgrade all of the X server packages, and if this fixed the slowdown, 
> then that would prove that the regression was in the X server.
> 
> But it seems that you already have x11perf results which demonstrate an X 
> server performance regression. Fixing this may or may not fix the Xfce 
> slowdown. It remains to be seen.
> 
>> e) Moving and resizing windows might be faster in all versions of Debian 
>> if the default setting would be to highlight only the window borders 
>> while moving or resizing, instead of including the window contents. This 
>> is probably an Xfce setting.
>>
> 
> Right. If Xfce doesn't offer this feature, there are certainly other 
> window managers that do offer this.

ok.  It appears that Gnome and KDE both require systemd now, at least in
Debian, and twm is a bit limited.  I think Xfce uses fvwm, so I could
probably use fvwm separately without Xfce (say, by starting X with
startx).  It's probably also possible to compile gnome and KDE without
systemd support, but that's beyond the scope of the current tests and
might break other things (in Debian).

> 
> If this is an Xfce bug, you'll need to file a bug report against that 
> package, in order to reach the relevant developers.
> 

[toc] | [prev] | [next] | [standalone]

#964225 — Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

On Thu, 11 Jul 2019, userm57@yahoo.com wrote:

> 
> No, for all the tests today, I used 4.19.56-debian-pmac, with the same
> kernel command line (except for root=).
> 

Right. My mistake.

> > > d) It takes approximately three seconds to open an xfce4-terminal in
> > > Debian 8.11, six seconds in Debian sid.
> ...
> > 
> > If you were to patch the X server, or change the xorg.conf (e.g. shadowfb) 
> 
> Shadowfb has no effect for mach64. 

I haven't seen any results that confirm this. Your results seem to show 
that the xorg.conf change was bogus.

Moreover, the X server logs show that the shadow framebuffer was never 
actually enabled for any mach64 test.

So it's an open question.

> I didn't test it for fbdev.

Actually, all of your fbdev tests use the shadow framebuffer, according to 
the X server logs. As Michel said, that's the default for fbdev. That's 
all good. The shadowfb test is only relevant as a workaround for the 
mach64 bug.

Anyway, the point I was trying to make here was simply that Xfce issues 
aren't necessarily X server issues (though they may be).

-- 

[toc] | [prev] | [next] | [standalone]

#964227 — Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

On 7/11/19 8:15 PM, Finn Thain wrote:
> On Thu, 11 Jul 2019, userm57@yahoo.com wrote:
> ...
>>
>> Shadowfb has no effect for mach64. 
> 
> I haven't seen any results that confirm this. Your results seem to show 
> that the xorg.conf change was bogus.
> 
> Moreover, the X server logs show that the shadow framebuffer was never 
> actually enabled for any mach64 test.
> 
> So it's an open question.
> ...

Please see Xorg_sid_mach64.log.

That file has this line:

[ 16529.773] (WW) MACH64(0): Cannot shadow an accelerated frame buffer.

I take that to mean that shadowing can not work for mach64, so it is
explicitly disabled regardless of whether it is specified in an
xorg.conf file (and it must be specified somewhere by default for
mach64, since I didn't use any custom xorg.conf files).  That same
message, and no other message related to shadowing, appears in the Xorg
log regardless of whether shadowfb (or shadow_fb) is set to "true" or
"false" in a custom /etc/X11/xorg.conf file:

Section "Device"
	Identifier "Mach64"
	Driver "mach64"
	Option "shadowfb" "true"
EndSection

This was seen in an earlier Xorg.log file that I may have only reported
but did not include (it showed that /etc/X11/xorg.conf was read and no
errors were logged regarding that file, though the above warning was
included regardless of the shadowfb, or shadow_fb, setting).

[toc] | [prev] | [next] | [standalone]

#964264 — Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

On Thu, 11 Jul 2019, userm57@yahoo.com wrote:

> On 7/11/19 8:15 PM, Finn Thain wrote:
> > On Thu, 11 Jul 2019, userm57@yahoo.com wrote:
> > ...
> >>
> >> Shadowfb has no effect for mach64.
> > 
> > I haven't seen any results that confirm this. Your results seem to 
> > show that the xorg.conf change was bogus.
> > 
> > Moreover, the X server logs show that the shadow framebuffer was never 
> > actually enabled for any mach64 test.
> > 
> > So it's an open question.
> > ...
> 
> Please see Xorg_sid_mach64.log.
> 
> That file has this line:
> 
> [ 16529.773] (WW) MACH64(0): Cannot shadow an accelerated frame buffer.
> 
> I take that to mean that shadowing can not work for mach64, so it is 
> explicitly disabled regardless of whether it is specified in an 
> xorg.conf file (and it must be specified somewhere by default for 
> mach64, since I didn't use any custom xorg.conf files).

Alternatively, "cannot shadow an accelerated frame buffer" could imply 
that we need to disable acceleration for mach64.

> That same message, and no other message related to shadowing, appears in 
> the Xorg log regardless of whether shadowfb (or shadow_fb) is set to 
> "true" or "false" in a custom /etc/X11/xorg.conf file:
> 

But why would the above warning message show up if shadowfb were in fact 
disabled by xorg.conf? I take the warning to mean that the xorg.conf I 
provided is bogus.

Anyway, I can't offer a config that would enable/disable acceleration or 
enable/disable shadowed framebuffer, so I'll leave it with Michel to 
pursue that workaround if he wishes to.

-- 

[toc] | [prev] | [next] | [standalone]

#964243 — Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

On 2019-07-11 6:49 p.m., userm57@yahoo.com wrote:
> 
> b) I was not able to install Michel's patch -- I wasn't sure what
> compile or other options to use.  It looks like I could build a new
> kernel with that (patched) module; would that be the best way to include
> the patch?  I see that a commit was made yesterday (Jul 10) related to
> the patch, so I can just wait and test it when it's available in Debian
> sid, or I can build a new kernel with the patch included.  Please advise.

It's an xf86-video-mach64 / xserver-xorg-video-mach64 patch, not a
kernel one. And yes, it's been merged to upstream Git master:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-mach64/commit/37498721a520cd1cff367bc36b1ac74b343826ca


-- 
Earthling Michel Dänzer               |              https://www.amd.com
Libre software enthusiast             |             Mesa and X developer

[toc] | [prev] | [next] | [standalone]

#964263 — Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

On Fri, 12 Jul 2019, Michel D?nzer wrote:

> On 2019-07-11 6:49 p.m., userm57@yahoo.com wrote:
> > 
> > b) I was not able to install Michel's patch -- I wasn't sure what 
> > compile or other options to use.  It looks like I could build a new 
> > kernel with that (patched) module; would that be the best way to 
> > include the patch?  I see that a commit was made yesterday (Jul 10) 
> > related to the patch, so I can just wait and test it when it's 
> > available in Debian sid, or I can build a new kernel with the patch 
> > included.  Please advise.
> 
> It's an xf86-video-mach64 / xserver-xorg-video-mach64 patch, not a 
> kernel one. And yes, it's been merged to upstream Git master: 
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-mach64/commit/37498721a520cd1cff367bc36b1ac74b343826ca
> 

Do you plan to backport this commit for Debian's packages?

-- 

[toc] | [prev] | [next] | [standalone]

#964265 — Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

On 2019-07-12 12:07 p.m., Finn Thain wrote:
> On Fri, 12 Jul 2019, Michel D?nzer wrote:
>> On 2019-07-11 6:49 p.m., userm57@yahoo.com wrote:
>>>
>>> b) I was not able to install Michel's patch -- I wasn't sure what 
>>> compile or other options to use.  It looks like I could build a new 
>>> kernel with that (patched) module; would that be the best way to 
>>> include the patch?  I see that a commit was made yesterday (Jul 10) 
>>> related to the patch, so I can just wait and test it when it's 
>>> available in Debian sid, or I can build a new kernel with the patch 
>>> included.  Please advise.
>>
>> It's an xf86-video-mach64 / xserver-xorg-video-mach64 patch, not a 
>> kernel one. And yes, it's been merged to upstream Git master: 
>> https://gitlab.freedesktop.org/xorg/driver/xf86-video-mach64/commit/37498721a520cd1cff367bc36b1ac74b343826ca
>>
> 
> Do you plan to backport this commit for Debian's packages?

I'm not involved in Debian packaging.


-- 
Earthling Michel Dänzer               |              https://www.amd.com
Libre software enthusiast             |             Mesa and X developer

[toc] | [prev] | [next] | [standalone]

#964351 — Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

On Fri, 12 Jul 2019, userm57@yahoo.com wrote:

> > Please see attached "all.tar.xz", which contains the following files:
> > 
> > "x11perf -all" tests:
> > 
> > 1) x11perf_8_fbdev.txt    : Debian 8.11, mach64 removed
> > 2) x11perf_8_mach64.txt   : Debian 8.11, mach64 installed
> > 3) x11perf_sid_fbdev.txt  : Debian sid, mach64 removed
> > 4) x11perf_sid_mach64.txt : Debian sid, mach64 installed
> > 5) x11perfcomp.txt        : comparison of the above four tests
> > 
> > "/var/log/Xorg.0.log" files:
> > 
> > 6) Xorg_8_fbdev.log      : Xorg log file for test (1)
> > 7) Xorg_8_mach64.log     : Xorg log file for test (2)
> > 8) Xorg_sid_fbdev.log    : Xorg log file for test (3)
> > 9) Xorg_sid_mach64.log   : Xorg log file for test (4)
> > 
> > "glxgears" (from mesa-utils) tests:
> > 
> > 10) glxgears.txt
> > ...
> 
> I added two tests.  Please see the attached "update.tar.xz", which
> contains the following six files:
> 
> "x11perf -all" tests:
> 
> 11) x11perf_sid_fbdev-1.txt  : Debian sid, mach64 removed, multiuser
> 12) x11perf_sid_mach64-1.txt : Debian sid, mach64 installed, multiuser
> 13) x11perfcomp_sid.txt      : comparison of 3), 4), 11) and 12)
> 
> "/var/log/Xorg.0.log" files:
> 
> 14) Xorg_sid_fbdev-1.log     : Xorg log file for 11)
> 15) Xorg_sid_mach64-1.log    : Xorg log file for 12)
> 
> serial console log:
> 
> 16) console_log.txt          : console log file for 11) and 12)
> 

Stan's x11perf benchmarks using fbdev show some serious regressions 
between xorg-server 2:1.16.4-1+deb8u2 and xorg-server 2:1.20.4-1.

The following test scores went backwards by more than 10 %.

34 % 500x500 tiled rectangle (216x208 tile)
30 % 100-pixel circle
28 % 500x500 tiled rectangle (161x145 tile)
26 % Circulate Unmapped window (200 kids)
26 % 500x500 tiled rectangle (17x15 tile)
25 % 100-pixel partial circle
25 % 100-pixel ellipse
25 % 100-pixel dashed circle
24 % Copy 500x500 from window to window
24 % 500x500 opaque stippled rectangle (17x15 stipple)
24 % 100-pixel wide ellipse
23 % Composite 500x500 from window to window
21 % 100x10 wide horizontal line segment
21 % 100-pixel horizontal line segment
20 % Char in 80-char aa line (Charter 10)
19 % Scroll 500x500 pixels
18 % Fill 100x100 equivalent triangle
17 % Char in 70-char line (8x13)
17 % 100-pixel fill chord partial ellipse
16 % 100-pixel dashed ellipse
15 % 100-pixel double-dashed ellipse
15 % 1-pixel solid circle
14 % 10-pixel vertical line segment
13 % PutImage XY 100x100 square
13 % Fill 300x300 tiled trapezoid (17x15 tile)
13 % Fill 100x100 equivalent complex polygons
12 % ShmGetImage XY 10x10 square
12 % Fill 100x100 trapezoid
12 % Char in 80-char rgb line (Charter 10)
12 % Char in 30-char line (TR 24)
12 % 100-pixel fill slice partial ellipse
11 % PutImage XY 500x500 square
11 % 500x500 rectangle
11 % 500x500 opaque stippled rectangle (161x145 stipple)
11 % 10x10 tiled rectangle (161x145 tile)
10 % Copy 500x500 1-bit deep plane
10 % Char in 30-char aa line (Charter 24)
10 % 500-pixel vertical line segment
10 % 10-pixel dashed segment

Those are the worst regressions. In total, 40% of x11perf measurements 
have regressed (though there's probably some measurement variation).

Michel, since this is fbdev not mach64, the bug you found cannot have 
caused this. Is this problem confined to powerpc or does it also appear in 
other Xorg regression tests?

-- 

[toc] | [prev] | [next] | [standalone]

#964651 — Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

On 2019-07-13 2:25 a.m., Finn Thain wrote:
> 
> Michel, since this is fbdev not mach64, the bug you found cannot have 
> caused this. Is this problem confined to powerpc or does it also appear in 
> other Xorg regression tests?

I don't know, but I don't think it matters too much; the goal should be
to enable HW acceleration again.


-- 
Earthling Michel Dänzer               |              https://www.amd.com
Libre software enthusiast             |             Mesa and X developer

[toc] | [prev] | [next] | [standalone]

#964655 — Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)

On Mon, 15 Jul 2019, Michel D?nzer wrote:

> On 2019-07-13 2:25 a.m., Finn Thain wrote:
> > 
> > Michel, since this is fbdev not mach64, the bug you found cannot have 
> > caused this. Is this problem confined to powerpc or does it also 
> > appear in other Xorg regression tests?
> 
> I don't know,

Does no-one measure this?

> but I don't think it matters too much

Linux has more than 100 fbdev drivers. Xorg's fbdev support for all that 
hardware is worth something, isn't it?

-- 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web