linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] The future of framebuffer

[Sven <lu...@dp...>]

On Thu, Sep 27, 2001 at 02:09:56PM +0400, Nick Kurshev wrote:
> Hello, GOTO!
> On Thu, 27 Sep 2001 18:25:19 +0900, you wrote:
> 
> > Hi, 
> > 
> > At Thu, 27 Sep 2001 09:59:52 +0400,
> > Nick Kurshev <nic...@ma...> wrote:
> > > > At Wed, 26 Sep 2001 12:40:47 +0400,
> > > > Nick Kurshev <nic...@ma...> wrote:
> > > > > 2. What about NLS support?
> > > > > Since I have localized linux distribution - I can not read
> > > > > any messages which is written not in English.
> > > > 
> > > > Is this console program or kernel issue?
> > > > fbcon is ready for single byte characters, and
> > > > jfbterm is ready for more complex language like UTF, EUC, ISO-2022.
> > > > Also console-tools is becoming ready for single byte characters and
> > > > UTF-8. But I've never seen multibyte characters with default
> > > > terminal (with console-tools).
> > > > 
> > > > -- gotom
> > > > 
> > > As I see NLS depends on drivers/video/font_8x??.c which were generated by cpi2font.
> > > Curently Linux has only english version of these files.
> > 
> > Right. Currently there is only ISO-8859-1 characters.
> > Is it useful to add more characters for ISO-8859-x or
> > KOI-8 people ?
> > I'm interesting, but I don't know whether there are some demands or not.
> > 
> > But, adding more complex characters like EUC and ISO-2022
> > is more difficult, because they are multibyte characters.
> > Handling them is some more hack.
> > Their character file is very big because their font have
> > more than 30000. Full or partial UTF-8 support invites
> > this problem. These days linux has large nls file in fs/nls,
> > so I think it's ok, but someone complain about this issue...
> > 
> > -- gotom
> > 
> I guess - it's big problem. Indeed linux should has full collections
> of different fonts. But it will make distributive too huge.
> IMHO it would be better to move out such packages (like fbdev) from kernel

Huh, why move all the fbdev out, the only thing you need to modularize is the
fonts used, not the fbdev.

BTW, can't we generate the fonts from the ones used by vgacon ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] ATI Rage XL Framebuffer (atyfb) Support

[Meelis R. <mr...@li...>]

> I have been unable to get my ATI Rage XL board working properly with the
> atyfb.c framebuffer driver.  Has anyone had any luck running the Rage with
> the aty framebuffer driver.  Eventually, I need to port this to a mips board,
> so using a VESA or VGA framebuffer driver will not be a viable solution.

I am using it with Rage XL on sparc64 (Sun Blade 100) every day. It mostly
works. Two known problems:

* on Sun, wrong memory clock is used by default. It's 120 (maybe the
PC versions of the card use this). The builtin one in Blade 100 has lower
clock. I use atyfb:mclk:100 and it works, don't know what's the right one. 120
causes snow-like effect on screen on most (but not all) bootups. There's a
comment in source that tells we might want to read the memory clocks from
OpenPROM but no-one has implemented it yet.

* Console switching from X does not work. Switching between text consoles
(using atyfb) works but changing from X to text console hangs the computer.
Probably a problem with X (XF 4.0.1, debian unstable).

Otherwise, no problems. Well, X may be somewhat slow, but then again, it's
probably X at fault.

-- 
Meelis Roos (mr...@li...)

Re: [Linux-fbdev-devel] The future of framebuffer

[Nick K. <nic...@ma...>]

Hello, GOTO!
On Thu, 27 Sep 2001 18:25:19 +0900, you wrote:

> Hi, 
> 
> At Thu, 27 Sep 2001 09:59:52 +0400,
> Nick Kurshev <nic...@ma...> wrote:
> > > At Wed, 26 Sep 2001 12:40:47 +0400,
> > > Nick Kurshev <nic...@ma...> wrote:
> > > > 2. What about NLS support?
> > > > Since I have localized linux distribution - I can not read
> > > > any messages which is written not in English.
> > > 
> > > Is this console program or kernel issue?
> > > fbcon is ready for single byte characters, and
> > > jfbterm is ready for more complex language like UTF, EUC, ISO-2022.
> > > Also console-tools is becoming ready for single byte characters and
> > > UTF-8. But I've never seen multibyte characters with default
> > > terminal (with console-tools).
> > > 
> > > -- gotom
> > > 
> > As I see NLS depends on drivers/video/font_8x??.c which were generated by cpi2font.
> > Curently Linux has only english version of these files.
> 
> Right. Currently there is only ISO-8859-1 characters.
> Is it useful to add more characters for ISO-8859-x or
> KOI-8 people ?
> I'm interesting, but I don't know whether there are some demands or not.
> 
> But, adding more complex characters like EUC and ISO-2022
> is more difficult, because they are multibyte characters.
> Handling them is some more hack.
> Their character file is very big because their font have
> more than 30000. Full or partial UTF-8 support invites
> this problem. These days linux has large nls file in fs/nls,
> so I think it's ok, but someone complain about this issue...
> 
> -- gotom
> 
I guess - it's big problem. Indeed linux should has full collections
of different fonts. But it will make distributive too huge.
IMHO it would be better to move out such packages (like fbdev) from kernel
and have it as 3-rd addons (plugins) for kernel. In this case the
site (for example linux-fbdev) should contain the full collection
of fonts. Each font should be downloadable independedly.
But it will possible if linux presidents will want to add
link on 3rd drivers from /lib/modules/kernel-ver (for example
/lib/modules/kernel-ver/3rd-drivers) which should point to permanent location.
Otherwise people will copy such drivers manually after each kernel updating.


Best regards! Nick

[Linux-fbdev-devel] Re: FB, video, FOURCC code

[Romain D. <do...@ir...>]

Romain Dolbeau wrote:

> Still, I guess I should use them ; I think I could add
> a 'number of FOURCC supported' field in the
> "struct fb_vidoverlay_avail", and add (yet) another
> ioctl to get only the variable-length FOURCC list.

F-up myself, here's an updated file. The sample implementation
in pm3fb compile (not near thebox, can't test it yet :-)

Any comment/criticism/improvement/advice very much welcome.

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: [Linux-fbdev-devel] The future of framebuffer

[GOTO M. <go...@de...>]

Hi, 

At Thu, 27 Sep 2001 09:59:52 +0400,
Nick Kurshev <nic...@ma...> wrote:
> > At Wed, 26 Sep 2001 12:40:47 +0400,
> > Nick Kurshev <nic...@ma...> wrote:
> > > 2. What about NLS support?
> > > Since I have localized linux distribution - I can not read
> > > any messages which is written not in English.
> > 
> > Is this console program or kernel issue?
> > fbcon is ready for single byte characters, and
> > jfbterm is ready for more complex language like UTF, EUC, ISO-2022.
> > Also console-tools is becoming ready for single byte characters and
> > UTF-8. But I've never seen multibyte characters with default
> > terminal (with console-tools).
> > 
> > -- gotom
> > 
> As I see NLS depends on drivers/video/font_8x??.c which were generated by cpi2font.
> Curently Linux has only english version of these files.

Right. Currently there is only ISO-8859-1 characters.
Is it useful to add more characters for ISO-8859-x or
KOI-8 people ?
I'm interesting, but I don't know whether there are some demands or not.

But, adding more complex characters like EUC and ISO-2022
is more difficult, because they are multibyte characters.
Handling them is some more hack.
Their character file is very big because their font have
more than 30000. Full or partial UTF-8 support invites
this problem. These days linux has large nls file in fs/nls,
so I think it's ok, but someone complain about this issue...

-- gotom

[Linux-fbdev-devel] FB, video, FOURCC code (was: The future of framebuffer)

[Romain D. <do...@ir...>]

Nick Kurshev wrote:

> As I've found - mplayer knows much more video image formats:
> 
> file main/libvo2/img_format.h

Yes, FOURCC code. You're not the first one to mention them...

The problem is, there's a bunch of them (see
<http://www.webartz.com/fourcc/>, for those who don't know
them), and advertising them isn't easy...

Still, I guess I should use them ; I think I could add
a 'number of FOURCC supported' field in the
"struct fb_vidoverlay_avail", and add (yet) another
ioctl to get only the variable-length FOURCC list.

BTW, what do the linux-console folks think of adding
video overlay support to Ruby ?

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: [Linux-fbdev-devel] The future of framebuffer

[Nick K. <nic...@ma...>]

Hello, GOTO!
On Thu, 27 Sep 2001 10:40:08 +0900, you wrote:

> At Wed, 26 Sep 2001 12:40:47 +0400,
> Nick Kurshev <nic...@ma...> wrote:
> > 2. What about NLS support?
> > Since I have localized linux distribution - I can not read
> > any messages which is written not in English.
> 
> Is this console program or kernel issue?
> fbcon is ready for single byte characters, and
> jfbterm is ready for more complex language like UTF, EUC, ISO-2022.
> Also console-tools is becoming ready for single byte characters and
> UTF-8. But I've never seen multibyte characters with default
> terminal (with console-tools).
> 
> -- gotom
> 
As I see NLS depends on drivers/video/font_8x??.c which were generated by cpi2font.
Curently Linux has only english version of these files.

Best regards! Nick

Re: [Linux-fbdev-devel] The future of framebuffer

[GOTO M. <go...@de...>]

At Wed, 26 Sep 2001 12:40:47 +0400,
Nick Kurshev <nic...@ma...> wrote:
> 2. What about NLS support?
> Since I have localized linux distribution - I can not read
> any messages which is written not in English.

Is this console program or kernel issue?
fbcon is ready for single byte characters, and
jfbterm is ready for more complex language like UTF, EUC, ISO-2022.
Also console-tools is becoming ready for single byte characters and
UTF-8. But I've never seen multibyte characters with default
terminal (with console-tools).

-- gotom

Re: [Linux-fbdev-devel] The future of framebuffer

[Romain D. <do...@ir...>]

Nick Kurshev wrote:

> 1. What about adding video extensions to devfb?

Well, it would need a standard way of querying the video
capability of the chip and using it. Not easy...
I've written a draft proposal for that, amd implemented
it in pm3fb (my fb driver for the permedia3), but it still
needs discussion. If there's interest in it, the likely
target would be kernel 2.5.x in Ruby (the new framebuffer
layer, see <http://sourceforge.net/projects/linuxconsole/>

Appended is the preliminary include file.

Any comment/criticism/improvement/advice very much welcome.

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

[Linux-fbdev-devel] The future of framebuffer

[Nick K. <nic...@ma...>]

Hello!

I have some questions about future of framebuffer.
I'm wroting to this mailing list simply because I don't know where
I can discuss further development of framebuffer technology.

1. What about adding video extensions to devfb?
Many modern chips can accelerate video decoding. Since fbdev
technology lacks such extensions in inet exist drivers
which are fbdev based and were specially designed to speedup
video decoding. They work through ioctls. Since framebuffer
supports ioctls IMHO it would be better to standardize this
feature to have possibility to expand existing drivers in this way.
Samples: http://mplayerhq.hu/cgi-bin/cvsweb.cgi/main/drivers
At least linux-kernel will contain them and people will not
need to compile them independetly and install them manually.

2. What about NLS support?
Since I have localized linux distribution - I can not read
any messages which is written not in English.

3. Does exist any way to unload framebuffer module?
I get only dead console when I try execute rmmod radeonfb.
I ask other people which have non radeon frame buffers and
they reported me about the same problems.

Best regards! Nick

P.S.: Please CC me - I'm not subscribed.

[Linux-fbdev-devel] ATI Rage XL Framebuffer (atyfb) Support

[Bart C. W. <bw...@li...>]

I have been unable to get my ATI Rage XL board working properly with the atyfb.c framebuffer driver.  Has anyone had any luck running the Rage with the aty framebuffer driver.  Eventually, I need to port this to a mips board, so using a VESA or VGA framebuffer driver will not be a viable solution.

Bart    

[Linux-fbdev-devel] PROBLEM: virtual terminal output to wrong destination

[Javier V. <ja...@mi...>]

UFJPQkxFTTogdmlydHVhbCB0ZXJtaW5hbCBvdXRwdXQgdG8gd3JvbmcgZGVzdGluYXRpb24NCg0K
SGkuDQoNClRoZSBmb2xsb3dpbmcgY2FuIHJhbmdlIGZyb20gdHdvIHNpbXVsdGFuZW91cyBidWdz
IGluIHR3byBkaWZmZXJlbnQNCmtlcm5lbCBtb2R1bGVzLCB0byBzb21ldGhpbmcgbWlzc2luZyBp
biB0aGUgc3dpdGNoaW5nIG9mIHZpcnR1YWwNCnRlcm1pbmFscyAoQWx0K0Z4KSwgdGlsbCB0byBz
b21ldGhpbmcgdGhlIGh1bWFuIG1pbmQgY2FuJ3QsIGFuZA0Kc2hvdWxkbid0LCB1bmRlcnN0YW5k
Lg0KDQpCcmllZmx5LCB0aGVzZSBhcmUgdGhlIHR3byBtb2R1bGVzIGFmZmVjdGVkOg0KLW1nYWNv
bi5jOiAyNSBsaW5lcyB0ZXh0IHZpcnR1YWwgdGVybWluYWwgb24gdGV4dCBtb25vY2hyb21lIGFk
YXB0ZXJzLg0KLWhnYWZiLmM6IGZyYW1lYnVmZmVyIHZpcnR1YWwgdGVybWluYWwgb24gSGVyY3Vs
ZXMgbW9ub2Nocm9tZSBncmFwaGljDQphZGFwdGVycy4NCkluIGJvdGggY2FzZXMsIHZpcnR1YWwg
dGVybWluYWwgb3V0cHV0IHRvd2FyZHMgdGhlc2UgY2FyZHMgYXBwZWFyIG9uDQpvdGhlciBpbiBz
aXR1YXRpb25zIHRoYXQgZm9sbG93Lg0KDQpXaGF0IEkgaGF2ZSBpczoNCi1TdVNFIDcuMCB3aXRo
IGtlcm5lbCAyLjQuNy4NCi1QcmltYXJ5OiBTMyBBR1AgKG5vIGZiKS4NCi1TZWNvbmRhcnk6IE1h
dHJveCBNeXN0aXF1ZSAyMjAgUENJICh1c2luZyBmYiwgbW9kdWxlIG1hdHJveGZiX2Jhc2UpLg0K
LU90aGVyOiBjbG9uZSBIZXJjdWxlcyBNREEgSVNBICh1c2luZyBtZGFjb24sIGFuZCBoZ2FmYiAo
ZmIpKS4NCi0xOSIgKEFHUCkgYW5kIDE0IiAoUENJKSBjb2xvciBtb25pdG9ycywgYW5kIGEgbW9u
b2Nocm9tZSBtb25pdG9yIChJU0EpLg0KLXR0eTEgdG8gdHR5NiB3aWxsIGJlIGNvbnZlbnRpb25h
bCB0ZXh0IHZ0J3Mgb24gUzMgQUdQIChubyBmcmFtZWJ1ZmZlciksDQp0dHk3IHdpbCBiZSBmb3Ig
WCAobm90IHVzZWQgaGVyZSksIHR0eTggdG8gdHR5MTEgd2lsbCBiZSBmcmFtZWJ1ZmZlcg0KdnQn
cywgYW5kIHR0eTEyIHdpbGwgYmUgZm9yIG1kYWNvbiAodGV4dCAyNSBsaW5lcykuDQotTW9kdWxl
cyB0byBsb2FkIHdpbGwgYmUgbWF0cm94ZmJfYmFzZSwgbWRhY29uIGFuZCBoZ2FmYjsgdGhlc2Ug
bGFzdCB0d28NCmhhdmUgdGhlIHByb2JsZW1zICh2aXJ0dWFsIHRlcm1pbmFsIG91dHB1dCBhcHBl
YXJzIG9uIE1hdHJveCkuDQpBcyByZXBvcnRlZCBieSB2ZXJfbGludXg6DQpMaW51eCBjYXByaWNo
byAyLjQuNyAjMTUgVHVlIFNlcCAxOCAxMDozNDoxNiBDRVNUIDIwMDEgaTY4NiB1bmtub3duDQpH
bnUgQyAgICAgICAgICAgICAgICAgIDIuOTUuMg0KR251IG1ha2UgICAgICAgICAgICAgICAzLjc5
LjENCmJpbnV0aWxzICAgICAgICAgICAgICAgMi45LjUuMC4yNA0KdXRpbC1saW51eCAgICAgICAg
ICAgICAyLjEwbQ0KbW91bnQgICAgICAgICAgICAgICAgICAyLjEwbQ0KbW9kdXRpbHMgICAgICAg
ICAgICAgICAyLjQuMg0KZTJmc3Byb2dzICAgICAgICAgICAgICAxLjE4DQpQUFAgICAgICAgICAg
ICAgICAgICAgIDIuMy4xMQ0KTGludXggQyBMaWJyYXJ5ICAgICAgICB4ICAgMSByb290ICAgICBy
b290ICAgICAgNDA3MTAxNCBEZWMgMzAgIDIwMDANCi9saWIvbGliYy5zby42DQpEeW5hbWljIGxp
bmtlciAobGRkKSAgIDIuMS4zDQpQcm9jcHMgICAgICAgICAgICAgICAgIDIuMC42DQpOZXQtdG9v
bHMgICAgICAgICAgICAgIDEuNTYNCktiZCAgICAgICAgICAgICAgICAgICAgMC45OQ0KU2gtdXRp
bHMgICAgICAgICAgICAgICAyLjANCk1vZHVsZXMgTG9hZGVkICAgICAgICAgbWF0cm94ZmJfYmFz
ZSBtYXRyb3hmYl9EQUMxMDY0IG1hdHJveGZiX2FjY2VsDQpmYmNvbi1jZmIyNCBtYXRyb3hmYl9t
aXNjIGZiY29uLWNmYjMyIGZiY29uLWNmYjggZmJjb24tY2ZiMTYgaWRlLWZsb3BweQ0KbnRmcyB2
ZmF0IGZhdCBhbmFsb2cgbnM1NTggZ2FtZXBvcnQgZXZkZXYgam95ZGV2IGMtcWNhbSBoZ2FmYiBm
YmNvbi1oZ2ENCm1zcDM0MDAgdHVuZXIgdHZhdWRpbyBidHR2IHNhYTUyNDkgZWVwcm9tIHc4Mzc4
MWQgaTJjLXByb2MgaTJjLXZpYXBybw0KaTJjLWRldiBpMmMtYWxnby1iaXQgaTJjLWNvcmUgcGFy
cG9ydF9wYyBwbGlwIHBhcnBvcnQgM2M1OXggaXJ0dHkgM2M1MDkNCmlyZGEgZHNicjEwMCB2aWRl
b2RldiBrZXliZGV2IG1vdXNlZGV2IGhpZCBpbnB1dCB1aGNpIHVzYmNvcmUgc2VyaWFsDQoNCkNv
bmZpZ3VyYXRpb246DQotTWFpbiBrZXJuZWwgLmNvbmZpZyBsaW5lczoNCi4uLg0KQ09ORklHX0ZC
PXkNCkNPTkZJR19EVU1NWV9DT05TT0xFPXkNCkNPTkZJR19GQl9IR0E9bQ0KQ09ORklHX1ZJREVP
X1NFTEVDVD15DQpDT05GSUdfRkJfTUFUUk9YPW0NCkNPTkZJR19GQl9NQVRST1hfTVlTVElRVUU9
eQ0KQ09ORklHX0ZCQ09OX0hHQT1tDQpDT05GSUdfTURBX0NPTlNPTEU9bQ0KLi4uDQotT24gL2V0
Yy9saWxvLmNvbmYgKGZyYW1lYnVmZmVyIHR0eSdzKToNCi4uLg0KICBhcHBlbmQgPSIuLi4gdmlk
ZW89dmM6OC0xMSINCi4uLg0KLU9uIC9ldGMvaW5pdHRhYiAoYWxsIHR0eSdzKToNCi4uLg0KMTox
MjM6cmVzcGF3bjovc2Jpbi9taW5nZXR0eSAtLW5vY2xlYXIgdHR5MQ0KMjoxMjM6cmVzcGF3bjov
c2Jpbi9taW5nZXR0eSB0dHkyDQozOjEyMzpyZXNwYXduOi9zYmluL21pbmdldHR5IHR0eTMNCjQ6
MTIzOnJlc3Bhd246L3NiaW4vbWluZ2V0dHkgdHR5NA0KNToxMjM6cmVzcGF3bjovc2Jpbi9taW5n
ZXR0eSB0dHk1DQo2OjEyMzpyZXNwYXduOi9zYmluL21pbmdldHR5IHR0eTYNCjg6MTIzOnJlc3Bh
d246L3NiaW4vbWluZ2V0dHkgdHR5OA0KOToxMjM6cmVzcGF3bjovc2Jpbi9taW5nZXR0eSB0dHk5
DQoxMDoxMjM6cmVzcGF3bjovc2Jpbi9taW5nZXR0eSB0dHkxMA0KMTE6MTIzOnJlc3Bhd246L3Ni
aW4vbWluZ2V0dHkgdHR5MTENCjEyOjEyMzpyZXNwYXduOi9zYmluL21pbmdldHR5IHR0eTEyDQou
Li4NCi1PbiAvZXRjL21vZHVsZXMuY29uZiAob3B0aW9ucyBmb3IgbWRhY29uIGFuZCBtYXRyb3hm
Yik6DQouLi4NCm9wdGlvbnMgbWRhY29uIG1kYV9maXJzdF92Yz0xMiBtZGFfbGFzdF92Yz0xMg0K
b3B0aW9ucyBtYXRyb3hmYl9iYXNlIGRldj0wIHZlc2E9MHgxMEMNCi4uLg0KDQpIb3cgdG8gcmVw
cm9kdWNlIGJvdGggYnVncyBmb2xsb3cgKEkgZGVzY3JpYmUgdGhlbSBzZXBhcmF0ZWx5LCBzaW5j
ZSBJDQpkb24ndCBrbm93IGEgY29tbW9uIHRoaW5nIGZvciBib3RoIGZhaWx1cmVzKS4NCg0KKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqDQoNCi0tLS0tLS0tLS0tLS0tQlVHIE9OIG1kYWNvbi5jLS0tLS0tLS0tLS0tLS0NCg0K
VG8gc2hvdyB0aGUgYnVnOg0KLTEpLiAnbW9kcHJvYmUgbWRhY29uJzogdGV4dCB2dCB0dHkxMiAy
NSBsaW5lcyBvbiBNREEgbW9uaXRvci4gSSBjYW4NCmxvZyBpbiB0aGVyZSAoQWx0K0YxMikuDQot
MikuICdtb2Rwcm9iZSBtYXRyb3hmYl9iYXNlJyAod2l0aCBvciB3aXRob3V0IGNvbjJmYik6IGZi
IHZ0J3MgKHR0eTgNCnRvIHR0eTExKSBvbiBNYXRyb3guIEkgY2FuIGxvZyBpbiBhcyB3ZWxsIChB
bHQrRjggdG8gQWx0K0YxMSkuDQotMykuIEFsdCtGMTIgdG8gcmV0dXJuIHRvIHZ0IG9uIE1EQTog
dGV4dCBhcHBlYXJzIGluIE1hdHJveCBtb25pdG9yLA0KaW5zdGVhZCBvZiBnb2luZyB0byBNREEg
bW9uaXRvci4gQ3Vyc29yIG1vdmVzIG9uIHRoZSBNREEgbW9uaXRvcjsNCnJlc3QgaXMgYmxhY2su
IExldHRlcnMgYXBwZWFyIG9uIE1hdHJveCBtb25pdG9yIHdpdGggb25lIHNwYWNlIGluDQpiZXR3
ZWVuLCBzdXJlbHkgYmVjYXVzZSBtZGFjb24gc2VuZGluZyB0aGUgdGV4dCBhdHRyaWJ1dGUgYnl0
ZS4NCg0KU28gbWRhY29uIHNlZW1zIG5vdCB0byBrbm93IHdoZXJlIGl0cyBvdXRwdXQgc2hvdWxk
IGFwcGVhci4NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqDQoNCi0tLS0tLS0tLS0tLS0tQlVHIE9OIGhnYWZiLmMtLS0t
LS0tLS0tLS0tLQ0KDQpIZXJlIGl0IGlzIGludGVuZGVkIHRvIG1ha2UgY29leGlzdCBmcmFtZWJ1
ZmZlciB2dCdzIG9uIE1hdHJveCBhbmQNCkhlcmN1bGVzLg0KDQpJIGJ1aWx0IHR3byBmaWxlcyB0
byBhc3NpZ24gdHR5J3MgdG8gZmIncyAoc2VlIGFib3ZlIGxpbmUgb24NCi9ldGMvbGlsby5jb25m
KToNCi1mYmg6DQptb2Rwcm9iZSBoZ2FmYg0KY29uMmZiIC9kZXYvZmIwIC9kZXYvdHR5MTANCmNv
bjJmYiAvZGV2L2ZiMCAvZGV2L3R0eTExDQotZmJtOg0KbW9kcHJvYmUgbWF0cm94ZmJfYmFzZQ0K
Y29uMmZiIC9kZXYvZmIxIC9kZXYvdHR5OA0KY29uMmZiIC9kZXYvZmIxIC9kZXYvdHR5OQ0KYW5k
IHByb2NlZWRlZCBzdGVwIGJ5IHN0ZXAgYXMgZm9sbG93cywgc3RhcnRpbmcgb24gTURBIChmYmgg
YW5kIGZibQ0KZXhlY3V0ZWQgZnJvbSB0dHkxIG9uIFMzIEFHUCkuDQoNCjEpIEV4ZWN1dGUgZmJo
LiB0dHkxMCBhbmQgdHR5MTEgYXBwZWFyIG9uIE1EQSBtb25pdG9yLCBhbmQgSSBjYW4gbG9nDQpp
bnRvIGJvdGggKHdlbGwsIEkgbXVzdCBndWVzcyAnbG9naW46ICcgYXBwZWFycywgYnV0ICdwYXNz
d29yZDogJyBkb2VzDQphcHBlYXIpLg0KDQoyKSBFeGVjdXRlIGZibS4gdHR5OCBhbmQgdHR5OSBh
cHBlYXIgb24gTWF0cm94IG1vbml0b3IsIGFuZCBJIGNhbiBhbHNvDQpsb2cgaW4uDQoNCjMpIENo
ZWNrIGxzbW9kOiBib3RoIGdyb3VwcyBvZiBmYiBtb2R1bGVzIChtYXRyb3hmYi9oZ2FmYiBhbmQg
b3RoZXJzKQ0KYXBwZWFyLg0KDQo0KSBCdXQgbm93IGdvaW5nIGJhY2sgdG8gTURBIHZ0J3MgdHR5
MTAgYW5kIHR0eTExIChBbHQrRjEwLCBBbHQrRjExKSwNCk1EQSBtb25pdG9yIGRvZXMgbm90IGNo
YW5nZSwgYW5kIGEgbWVzcyBhcHBlYXJzIGluIE1hdHJveCBtb25pdG9yOg0Kb3V0cHV0DQpnb2Vz
IGVycm9uZW91c2x5IHRoZXJlLCBNREEgY29tbWFuZHMgbWFrZSBubyBzZW5zZSBmb3IgTWF0cm94
LCBhbmQgd2hhdA0KYXBwZWFycyBpcyBtYW55IGNvbG9yZWQgcmVjdGFuZ2xlcy4NCg0KNSkgTWF0
cm94IHZ0J3Mgc3RpbGwgYXBwZWFyIG5vcm1hbGx5IG9uIE1hdHJveCBtb25pdG9yIChBbHQrRjgs
IEFsdCtGOSkuDQoNClNvIGhnYWZiIHNlZW1zIG5vdCB0byBrbm93IHdoZXJlIGl0cyBvdXRwdXQg
c2hvdWxkIGFwcGVhci4NCg0KSWYgdHJ5aW5nIGluIG9wcG9zaXRlIG9yZGVyLCBNYXRyb3ggdGhl
biBNREEgKHJlYm9vdGluZywgYW5kIHdpdGggdHdvDQpvdGhlciBzaW1pbGFyIGZpbGVzIGV4Y2hh
bmdpbmcgZmIwPC0+ZmIxKSBhbGwgb3V0cHV0IGdvZXMgdG8gTWF0cm94DQptb25pdG9yIChoZ2Fm
YiBtZXNzZWQpLg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioNCg0KSWYgdHJ5aW5nIGp1c3QgaGdhZmIgYW5kIG1kYWNv
biwgc28gbm90IGludm9sdmluZyBNYXRyb3gsIG91dHB1dCB0byBtZGFjb24gKEFsdCtGMTIpIHNl
ZW1zIHRyZWF0ZWQgYnkgaGdhZmIsIGFuZCB3aGF0IHlvdSBzZWUgb24gTURBIG1vbml0b3IgYXJl
IHNtYWxsIGRvdHMgKHRoZSBjYXJkIGRvZXMgbm90IHNlZW0gdG8gc3dpdGNoIHRvIHRleHQgbW9k
ZSkuIE91dHB1dCB0byBoZ2FmYiBpcyBub3JtYWwuIFNvIGhlcmUgbWRhY29uIG91dHB1dCBpcyBt
ZXNzZWQuDQoNCklmIHRyeWluZyBhbGwgdGhyZWUgbW9kdWxlcyBhdCB0aGUgdGltZSwgdGhpbmdz
IGdldCB3b3JzZS4NCg0KSFRILg0KDQpHcmVldGluZ3MsIEphdmllciBWaXpjYWluby4NCg0KKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQpKYXZpZXIgVml6Y2Fpbm8gIGphdml6
Y2FAbWkubWFkcml0ZWwuZXMNClN0YXJ0aW5nIHBvaW50OiAgICAgICAgKC0xKV4oLTEpID0gLTEN
CkFwcGx5aW5nIGxvZ2FyaXRobXM6ICgtMSkqbG4oLTEpID0gbG4oLTEpDQpTaW5jZSBsbigtMSk8
PjAsIGRpdmlkaW5nOiAgICAtMSA9IDENCg0K

[Linux-fbdev-devel] Re: [PATCH] fbdev config fixes (ac edition)

[Geert U. <Gee...@so...>]

On Wed, 19 Sep 2001, Alan Cox wrote:
> > Fix fbdev config glitches that were introduced recently:
> >   - Remove duplicate CONFIG_* section for DECstation
> >   - Remove duplicate initialization code for pmagbafb, pmagbbfb, and maxinefb
> 
> Please send those to Ra...@gn... not me

Will do. Note that the duplicates are not in Ralf's tree.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[Linux-fbdev-devel] Re: [PATCH] fbdev config fixes (ac edition)

[Alan C. <al...@lx...>]

> Fix fbdev config glitches that were introduced recently:
>   - Remove duplicate CONFIG_* section for DECstation
>   - Remove duplicate initialization code for pmagbafb, pmagbbfb, and maxinefb

Please send those to Ra...@gn... not me

>   - Sstfb doesn't use resource management, so move its initialization to the
>     correct section (why do people never read comments in source code?)

Grin - it will be doing that soon

[Linux-fbdev-devel] [PATCH] fbdev config fixes (ac edition)

[Geert U. <ge...@li...>]

	Hi Alan,

Fix fbdev config glitches that were introduced recently:
  - Remove duplicate CONFIG_* section for DECstation
  - Remove duplicate initialization code for pmagbafb, pmagbbfb, and maxinefb
  - Sstfb doesn't use resource management, so move its initialization to the
    correct section (why do people never read comments in source code?)

diff -urN linux-2.4.9-ac10/drivers/video/Config.in geert-2.4.9-ac10/drivers/video/Config.in
--- linux-2.4.9-ac10/drivers/video/Config.in	Thu Sep 13 10:37:07 2001
+++ geert-2.4.9-ac10/drivers/video/Config.in	Tue Sep 18 21:17:39 2001
@@ -199,13 +199,6 @@
    if [ "$CONFIG_NINO" = "y" ]; then
       bool '  TMPTX3912/PR31700 frame buffer support' CONFIG_FB_TX3912
    fi
-   if [ "$CONFIG_DECSTATION" = "y" ]; then
-     if [ "$CONFIG_TC" = "y" ]; then
-       bool '  PMAG-BA TURBOchannel framebuffer support' CONFIG_FB_PMAG_BA
-       bool '  PMAGB-B TURBOchannel framebuffer spport' CONFIG_FB_PMAGB_B
-       bool '  Maxine (Personal DECstation) onboard framebuffer spport' CONFIG_FB_MAXINE
-     fi
-   fi
    if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
       tristate '  Virtual Frame Buffer support (ONLY FOR TESTING!)' CONFIG_FB_VIRTUAL
    fi
diff -urN linux-2.4.9-ac10/drivers/video/fbmem.c geert-2.4.9-ac10/drivers/video/fbmem.c
--- linux-2.4.9-ac10/drivers/video/fbmem.c	Thu Sep 13 10:37:12 2001
+++ geert-2.4.9-ac10/drivers/video/fbmem.c	Tue Sep 18 21:25:47 2001
@@ -126,12 +126,6 @@
 extern int tx3912fb_init(void);
 extern int radeonfb_init(void);
 extern int radeonfb_setup(char*);
-extern int pmagbafb_init(void);
-extern int pmagbafb_setup(char *);
-extern int pmagbbfb_init(void);
-extern int pmagbbfb_setup(char *options, int *ints);
-extern void maxinefb_init(void);
-extern void maxinefb_setup(char *options, int *ints);
 extern int e1355fb_init(void);
 extern int e1355fb_setup(char*);
 extern int pvr2fb_init(void);
@@ -214,9 +208,6 @@
 #if defined(CONFIG_FB_SIS) && (defined(CONFIG_FB_SIS_300) || defined(CONFIG_FB_SIS_315))
 	{ "sisfb", sisfb_init, sisfb_setup },
 #endif
-#ifdef CONFIG_FB_VOODOO1
-	{ "sstfb", sstfb_init, sstfb_setup },
-#endif
 
 	/*
 	 * Generic drivers that are used as fallbacks
@@ -303,6 +294,9 @@
 #ifdef CONFIG_FB_MAXINE
 	{ "maxinefb", maxinefb_init, NULL },
 #endif
+#ifdef CONFIG_FB_VOODOO1
+	{ "sstfb", sstfb_init, sstfb_setup },
+#endif
 
 	/*
 	 * Generic drivers that don't use resource management (yet)
@@ -319,19 +313,6 @@
 	/* Not a real frame buffer device... */
 	{ "resolver", NULL, resolver_video_setup },
 #endif
-
-#ifdef CONFIG_FB_PMAG_BA
-       { "pmagbafb", pmagbafb_init, pmagbafb_setup },
-#endif
-#ifdef CONFIG_FB_PMAGB_B
-        { "pmagbbfb", pmagbbfb_init, pmagbbfb_setup },
-#endif
-
-#ifdef CONFIG_FB_MAXINE
-        { "maxinefb", maxinefb_init, NULL },
-#endif
-
-
 
 
 #ifdef CONFIG_FB_VIRTUAL

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[Linux-fbdev-devel] [PATCH] fbdev config fixes

[Geert U. <ge...@li...>]

	Hi Linus,

Fix fbdev config glitches that were introduced recently:
  - Remove selection of CONFIG_FB_ATY_CT_VAIO_LCD (code is not there yet. It
    exists in Alan's tree but is not mature)
  - Remove duplicate CONFIG_{FB_PMAG_BA,FB_PMAGB_B,FB_MAXINE}
  - Add missing initialization calls for pmagbafb, pmagbbfb, maxinefb,
    tx3912fb, and sstfb (code is there, so make it usable)

diff -urN linux-2.4.10-pre11/drivers/video/Config.in geert-2.4.10-pre11/drivers/video/Config.in
--- linux-2.4.10-pre11/drivers/video/Config.in	Thu Sep 13 10:37:07 2001
+++ geert-2.4.10-pre11/drivers/video/Config.in	Tue Sep 18 21:26:29 2001
@@ -135,9 +135,6 @@
 	 if [ "$CONFIG_FB_ATY" != "n" ]; then
 	    bool '    Mach64 GX support (EXPERIMENTAL)' CONFIG_FB_ATY_GX
 	    bool '    Mach64 CT/VT/GT/LT (incl. 3D RAGE) support' CONFIG_FB_ATY_CT
-	       if [ "$CONFIG_FB_ATY_CT" = "y" ]; then
-	          bool '      Sony Vaio C1VE 1024x480 LCD support' CONFIG_FB_ATY_CT_VAIO_LCD
-	       fi
 	 fi
  	 tristate '  ATI Radeon display support (EXPERIMENTAL)' CONFIG_FB_RADEON
 	 tristate '  ATI Rage128 display support (EXPERIMENTAL)' CONFIG_FB_ATY128
@@ -198,13 +195,6 @@
    fi
    if [ "$CONFIG_NINO" = "y" ]; then
       bool '  TMPTX3912/PR31700 frame buffer support' CONFIG_FB_TX3912
-   fi
-   if [ "$CONFIG_DECSTATION" = "y" ]; then
-     if [ "$CONFIG_TC" = "y" ]; then
-       bool '  PMAG-BA TURBOchannel framebuffer support' CONFIG_FB_PMAG_BA
-       bool '  PMAGB-B TURBOchannel framebuffer spport' CONFIG_FB_PMAGB_B
-       bool '  Maxine (Personal DECstation) onboard framebuffer spport' CONFIG_FB_MAXINE
-     fi
    fi
    if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
       tristate '  Virtual Frame Buffer support (ONLY FOR TESTING!)' CONFIG_FB_VIRTUAL
diff -urN linux-2.4.10-pre11/drivers/video/fbmem.c geert-2.4.10-pre11/drivers/video/fbmem.c
--- linux-2.4.10-pre11/drivers/video/fbmem.c	Tue Sep 18 10:52:36 2001
+++ geert-2.4.10-pre11/drivers/video/fbmem.c	Tue Sep 18 21:24:40 2001
@@ -118,12 +118,20 @@
 extern int sisfb_setup(char*);
 extern int stifb_init(void);
 extern int stifb_setup(char*);
+extern int pmagbafb_init(void);
+extern int pmagbafb_setup(char *);
+extern int pmagbbfb_init(void);
+extern int pmagbbfb_setup(char *options, int *ints);
+extern void maxinefb_init(void);
+extern int tx3912fb_init(void);
 extern int radeonfb_init(void);
 extern int radeonfb_setup(char*);
 extern int e1355fb_init(void);
 extern int e1355fb_setup(char*);
 extern int pvr2fb_init(void);
 extern int pvr2fb_setup(char*);
+extern int sstfb_init(void);
+extern int sstfb_setup(char*);
 
 static struct {
 	const char *name;
@@ -268,11 +276,26 @@
 #ifdef CONFIG_FB_HIT
 	{ "hitfb", hitfb_init, NULL },
 #endif
+#ifdef CONFIG_FB_TX3912
+	{ "tx3912", tx3912fb_init, NULL },
+#endif
 #ifdef CONFIG_FB_E1355
 	{ "e1355fb", e1355fb_init, e1355fb_setup },
 #endif
 #ifdef CONFIG_FB_PVR2
 	{ "pvr2", pvr2fb_init, pvr2fb_setup },
+#endif
+#ifdef CONFIG_FB_PMAG_BA
+	{ "pmagbafb", pmagbafb_init, pmagbafb_setup },
+#endif
+#ifdef CONFIG_FB_PMAGB_B
+	{ "pmagbbfb", pmagbbfb_init, pmagbbfb_setup },
+#endif
+#ifdef CONFIG_FB_MAXINE
+	{ "maxinefb", maxinefb_init, NULL },
+#endif
+#ifdef CONFIG_FB_VOODOO1
+	{ "sstfb", sstfb_init, sstfb_setup },
 #endif
 
 	/*

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] Portait to Lanscape

[Geert U. <ge...@li...>]

On Tue, 4 Sep 2001 pet...@ph... wrote:
> I'm using an intel assabet development board on which I swapped the display. The new display is a portait mode display
> and now I want to present my user interface in lanscape mode. Did somebody did this allready using the framebuffer??

For the text console, just supply your own drawing routines. Creating e.g.
fbcon-cfb8-rot90 from fbcon-cfb8 shouldn't be that difficult.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] Re: Linux-fbdev-devel digest, Vol 1 #163 - 1 msg

[Geert U. <Gee...@so...>]

On Thu, 30 Aug 2001, Chris Wright wrote:
> > Sorry for the following stupid questions, :) I am a new comer  to the
> > frame buffer devices of linux, I am supposed to write the frame buffer
> > device driver for scorpion graphic chip(Motorola MC92110 ) and  first
> > like to play around the frame buffer device like vfb or VESA. Could
> > anybody point me some simple examples to use this kind of devices, like
> > draw a line or...
> 
> Hello!  recently, a friend of mine and myself faced a similar challenge.
> unfortunately, there was no one to answer this, so we forged ahead
> blindly, and figured out what we could.  take a look at
> gdr.softpixel.com/spurtg for a program that uses framebuffer (we wrote
> this).  download the tarball, and take a look at gfx.c in the src dir.
> basically, you open the device, call some ioctl's (outlined in linux/fb.h
> i think), and thats all you need.  it helps to mmio it so it becomes a
> large array.  if you need some more help, we can try to help you out.

You can also take a look at the sources of fbtest (CVS module fbtest).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[Linux-fbdev-devel] ruby and pm3fb

[Sven <lu...@dp...>]

No, romain, i tried yesterday the changes you did to pm3fb on ruby, but still
it hangs at the same place.

Will check more when i have time (maybe tommorow, maybe on wednesday only
:((()

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Portait to Lanscape

[Florian L. <f.l...@ti...>]

Dear Mr. Hiddings,

	If you are interested I could send you the code. But have to tell you,
that it's not workin 100% there a pixel faults (top and or bottom) Just
a one day dirty hack. Couldn' do too much, cos was ocupied with a
smaller version of our hardware (CGA).

pet...@ph... wrote:
> 
> Florian,
> 
> For now I do not have created any code, so from  my side there is nothing to share. I was just wondering if anybody did solve the problem I have from which I could learn en re-use the code if possible.
> 
> Regards,
> 
> Peter
> 
> Florian Lechner <f.l...@ti...> on 2001/09/05 14:39:12
> 
> To:     Peter Hidding/EHV/COMP/PHILIPS@EMEA3
> cc:     lin...@li...
> Subject:  Re: [Linux-fbdev-devel] Portait to Lanscape
> Classification:
> 
> Dear Mr. Hiddings,
> 
>      not exactly, but I have flipped the framebuffer by 180° for a
> pos-terminal. Works only on x86 and not 100% still in development. I'm
> thinking about to extend it to rotate the display by 90°. We could share
> the code.
> 
> Regards Florian
> 
> pet...@ph... wrote:
> >
> > Hi,
> >
> > I'm using an intel assabet development board on which I swapped the display. The new display is a portait mode display
> > and now I want to present my user interface in lanscape mode. Did somebody did this allready using the framebuffer??
> >
> > Peter
> >
> > _______________________________________________
> > Linux-fbdev-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

[Linux-fbdev-devel] S3 928 stepping F

[Rogelio M. S. Jr. <ro...@ev...>]

My s3 return an id byte of 0x96. Can we consider this stepping 6? Can
this chip do truecolor then? My RAMDAC is an ATT20C490 and im using it
in 24 bit truecolor.

[Linux-fbdev-devel] initial success with S3 928 fbdev

[Rogelio M. S. Jr. <ro...@ev...>]

Ok I got it working. I copied code from X336. It is a rewrite of the
s3fb driver from mr. garzik. It has a linear mapped framebuffer, no
mmio, and it can do 16bpp. Im working on acceleration right now. I have
not used it much yet.

Re: [Linux-fbdev-devel] Portait to Lanscape

[<pet...@ph...>]

Florian,

For now I do not have created any code, so from  my side there is nothi=
ng to share. I was just wondering if anybody did solve the problem I ha=
ve from which I could learn en re-use the code if possible.

Regards,

Peter





Florian Lechner <f.l...@ti...> on 2001/09/05 14:39:12

To:     Peter Hidding/EHV/COMP/PHILIPS@EMEA3
cc:     lin...@li...
Subject:  Re: [Linux-fbdev-devel] Portait to Lanscape
Classification:



Dear Mr. Hiddings,

     not exactly, but I have flipped the framebuffer by 180=B0 for a
pos-terminal. Works only on x86 and not 100% still in development. I'm
thinking about to extend it to rotate the display by 90=B0. We could sh=
are
the code.

Regards Florian

pet...@ph... wrote:
>
> Hi,
>
> I'm using an intel assabet development board on which I swapped the d=
isplay. The new display is a portait mode display
> and now I want to present my user interface in lanscape mode. Did som=
ebody did this allready using the framebuffer??
>
> Peter
>
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel



=

Re: [Linux-fbdev-devel] Portait to Lanscape

[Florian L. <f.l...@ti...>]

Dear Mr. Hiddings,

	not exactly, but I have flipped the framebuffer by 180° for a
pos-terminal. Works only on x86 and not 100% still in development. I'm
thinking about to extend it to rotate the display by 90°. We could share
the code.

Regards Florian

pet...@ph... wrote:
> 
> Hi,
> 
> I'm using an intel assabet development board on which I swapped the display. The new display is a portait mode display
> and now I want to present my user interface in lanscape mode. Did somebody did this allready using the framebuffer??
> 
> Peter
> 
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [Linux-fbdev-devel] ruby on pm3/i386

[Sven L. <lu...@la...>]

On Tue, Sep 04, 2001 at 09:57:58AM +0200, Romain Dolbeau wrote:
> Sven Luther wrote:
> 
> > That said, does pm3fb + ruby work somewhere ?
> 
> non :-(

:)))

> > Does it work for you romain with
> > pm3fb on ppc, or for someone else on i386 ?
> 
> ruby marche pas sur PPC, et personne n'a essaye
> sur x86 a part toi...

mmm, meme pas pour james, avec un autre driver ?

ceci dis, je suis volontaire pour tester plus, meme si malheureusement j'ai
pas trop le temps de m'occuper de cela plus en detail :(((

BTW, as-tu essayer le nouveau driver Xv de Alan, cela semble marche bien pour
moi, mais plante lorsque je passe vlc en mode fullscreen.

Amicalement,

Sven Luther