linuxconsole-dev

Re: Patched Xfree86 4.3.0 in Debian

[Kjetil K. <kj...@kj...>]

On onsdag 19. mai 2004, 10:12, Svetoslav Slavtchev wrote:
> > Hehe, but you're saying that "SingleCard" is the option that
> > replaces the old "PrefBusID" in this patch?
>
> it doesn't replace it, its an addition,
> and IMO it's easier to use
> /* why specify BusID on 2 places,
> =A0when it could be just one */
> and it's the one that kept it's name in both patches :-)

Oh, OK, so I just need to skip "BusID" and use SingleCard instead of=20
both BusID and PrefBusID?

> > Well, the dual-head config didn't work when I installed the new
> > binaries, I guess there could be a reason for it... :-)
>
> can you explain a bit more?
> what do you think is the reason?

Dunno, but it feels awfully familiar... One consol gets garbage, I kill=20
the server, it restarts, takes the whole CPU, but I can log onto the=20
other.=20

Anyway, the problem is, I'm really under a lot of pressure at work right=20
now, head well below water, and my girlfriend, who was using the other=20
console, doesn't really need it now. So, I guess I just have to stay=20
away from big tweaking right now... Xinerama is cool too, you=20
know... :-)

> if it's the new patch, i'll stay with prefbusid
> (and will have to add debian notes :( )

Well, I would have to downgrade the packages, which can be a pain.=20

> anyone using IsolateDevice Xserver successfully ?

Andreas does.


> > Yup!
>
> ok,
> any other debian notes ?
> other general notes ?

Mmmmm, I guess Andreas would be better to address this, I think. But=20
he's possibly very busy too. They've got a big release soon, I think...=20

> > OK, I know that there are at least one much used archive at
> > http://marc.theaimsgroup.com/?q=3Dabout#Add
>
> that's my favourite :-)
> would you add them ?

Well, they want the list admins permission anyway, so perhaps the list=20
admin better make the contact...?=20

Best,

Kjetil
=2D-=20
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
kj...@kj...  web...@sk...  ed...@le...
Homepage: http://www.kjetil.kjernsmo.net/        OpenPGP KeyID: 6A6A0BBC

Re: Kernel summit/Desktop summit.

[James S. <jsi...@in...>]

> >well as the kernel summit. The kernel summit is unfortunely by 
> >invitation only :-( but the desktop one is open to the public. To the 
> >people that have worked hard on this project let me know if you want to go 
> >to the desktop summit. If you don't have the money I will work something 
> >out for you. I plan to give a demo of Ruby there!!!! So in the next few 
> >weeks I'm going to set up a box to send to the conference. 
> >
> >My goals for the demo are to have a 4 desktop system. I like to get KDE 
> >running on one desktop and Gnome on another. Then the other 2 heads would 
> >be a Embedded JVM running and a regular console. 
> >
> Ideally set up so the session type (gnome, kde, regular,...) is
> decided by login name rather than console number? Ability
> to use any console for anything is great, it avoids the problem
> of everybody wanting the "best" screen at home. :-)
> 
> Will you tell them about Zoltán Böszörményi's double 3D setup too? :-)

Yes.

Re: G550DH + G450DH Framebuffer succes & directfb question.

[Zoltan B. <zb...@fr...>]

James Simmons =EDrta:
>>Note that this didn't work well with 3D, last time I tried.
>>One server using 3D blocks the other xserver 99% of the time, meaning
>>the other user can't  work efficiently if the first user is using a gam=
e.
>>Even 2D operations get blocked like this.  3D on both servers were
>>impossible, even though two 3D clients on a single server works fine.
>=20
>=20
> :-(
>=20
>=20
>>Things seems to happen fast on the DRI front, but I don't really
>>expect this to work anytime soon.  Virtualizing the 3D accelerator
>>will make this "easy", but the implied slowdown might not be
>>desireable.
>>
>>Zolt=E1n B=F6sz=F6rm=E9nyi already showed dual 3D using two independent=
 cards
>>though, I believe that is the way to go for dual gaming.
>=20
>=20
> That was with the Nvidia closed driver?

No, this is with the plain FC1 XFree86 radeon driver.
I had to apply the latest DRI patch from the -mm tree
so it provides /dev/dri/card0 and /dev/dri/card1.
It detects the cards in bus/card order, so the
PCI radeon is card0 and the AGP radeon is card1.
I had to setup the servers in the same order in gdm.conf,
i.e. I have this in dmesg:

[drm] Initialized radeon 1.10.0 20020828 on minor 0: ATI Technologies=20
Inc Radeon RV100 QY [Radeon 7000/VE]
[drm] Initialized radeon 1.10.0 20020828 on minor 1: ATI Technologies=20
Inc RV280 [Radeon 9200 SE]

and this in gdm.conf:

[servers]
0=3DX0
1=3DX1

[server-X0]
name=3DX0 server
command=3D/usr/X11R6/bin/X -deferglyphs 16 -layout "First Head" vt7
flexible=3Dtrue

[server-X1]
name=3DX1 server
command=3D/usr/X11R6/bin/X -deferglyphs 16 -layout "Second Head" vt17
flexible=3Dtrue

and this in XF86Config:

Section "ServerLayout"
         Identifier     "First Head"
         Screen      0  "Screen0" 0 0
         InputDevice    "Mouse1" "CorePointer"
         InputDevice    "Keyboard0" "CoreKeyboard"
         Option      "SingleCard" "true"
EndSection
=20
=20
     Section "ServerLayout"
         Identifier     "Second Head"
         Screen      0  "Screen1" 0 0
         InputDevice    "Mouse0" "CorePointer"
         InputDevice    "Keyboard0" "CoreKeyboard"
         Option      "SingleCard" "true"
EndSection
...
Section "Device"
=20
=20
             Identifier  "Videocard1"
         Driver      "radeon"
         VendorName  "Videocard vendor"
         BoardName   "ATI Radeon 9200SE"
         Option      "AGPMode" "4"
         Option      "dpms" "off"
         BusID       "PCI:1:0:0"
EndSection
Section "Device"
         Identifier  "Videocard0"
         Driver      "radeon"
         VendorName  "Videocard vendor"
         BoardName   "ATI Radeon 7000"
         Option      "dpms" "off"
         BusID       "PCI:0:6:0"
EndSection
Section "Screen"
         Identifier "Screen0"
         Device     "Videocard0"
         Monitor    "Monitor0"
         DefaultDepth     16
         SubSection "Display"
...
EndSection
Section "Screen"
         Identifier "Screen1"
         Device     "Videocard1"
         Monitor    "Monitor0"
         DefaultDepth     24
         SubSection "Display"
...
EndSection

The XFree86-4.3.0 DRI detection gets confused if
the card initialization is reversed. It tries to
set the DRI "private" field to the card's PCI
BusID and it fails if its not the same as the
actual BusID and XFree86 gives up if the device
node is not already opened (busy) and the setting
this private field fails.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

Re: G550DH + G450DH Framebuffer succes & directfb question.

[James S. <jsi...@in...>]

> > I can try it. But I sent him missing memset() in matroxfb_maven
> > (which causes crash, not just ill behavior, and it is obviously
> > correct) three times and it still did not get through his email 
> > filters. So it is probably time to try to submit my pending patches
> > again. Last time I sent two one passed (ncpfs) and one was dropped
> > (matroxfb max/max_t and memset), so maybe that sending patches in 
> > batches increases probability that some will pass...
> 
> may be you should try sending them to Andrew 
> for -mm and lkml.
> 
> i've heard Linus has the habit to simply delete
> his inbox from time to time :-)

Hisis right. The best way to send patches is to Andrew Morton.

Re: G550DH + G450DH Framebuffer succes & directfb question.

[James S. <jsi...@in...>]

> Note that this didn't work well with 3D, last time I tried.
> One server using 3D blocks the other xserver 99% of the time, meaning
> the other user can't  work efficiently if the first user is using a game.
> Even 2D operations get blocked like this.  3D on both servers were
> impossible, even though two 3D clients on a single server works fine.

:-(
 
> Things seems to happen fast on the DRI front, but I don't really
> expect this to work anytime soon.  Virtualizing the 3D accelerator
> will make this "easy", but the implied slowdown might not be
> desireable. 
> 
> Zoltán Böszörményi already showed dual 3D using two independent cards
> though, I believe that is the way to go for dual gaming.

That was with the Nvidia closed driver?

Re: G550DH + G450DH Framebuffer succes & directfb question.

[James S. <jsi...@in...>]

> > I don't think the matroxset commands where 
> > meant to be used with the ruby kernel.
> 
> there is nothing wrong with matroxset with ruby,
> and it's the only way to separate the outputs 
> of the two heads of G4x0DH or G550DH
> else both fbdevs are mirrored :(
> 
> does anyone have a better solution ?
> 
> ( 
> of course it would be great to get independant fbcon 
> without matroxset, but i'm not aware of such possibility
> )

I haven't fixed it up but I do have a idea. It would also eliminate that 
awful driver init list in fbmem.c.  The idea was to send a event when a 
driver is registered. Then fbcon would recieve that event. Then it would 
look at the con2fb_map in fbcon to see what VCs to map to. At the boot 
command line or via con2fb you can set this mapping. Now if you have the 
case of a dual headed card where one head isn't mapped then it could 
default to mirroring. Fundamentally we need a mirror api for the fbdev 
layer. I'm hoping to introduce that via sysfs.

> IMO, this is only possible with the Matrox MMS series cards (G200 or G450)
> two/ four heads by choice(pocket) , but they are really too
> expensive
> it's just that the hardware is missing

So it is possible to run OpenGl on a Matrox card :-)

Re: G550DH + G450DH Framebuffer succes & directfb question.

[Petr V. <VAN...@vc...>]

On 19 May 04 at 13:40, Svetoslav Slavtchev wrote:
> > On 19 May 04 at 13:16, Svetoslav Slavtchev wrote:
> > > 
> > > and it would be nicer to not need matroxset in order
> > > to get two independant fbcon on G550
> > 
> > It would need sensing card outputs to find which outputs have connected
> > monitor and which do not, and as there is no doc...
> >  
> 
> isn't it possible to simply assume that both outputs
> have connected monitors ?
> or does the driver need to retrive monitor data,
> in order to setup properly ?

Problem is that "analog" (HD15) output on G550 is actually
secondary output. So you have to do:

nothing on DVI/nothing on HD15:        anything -> primary output,
                                       anything -> secondary output,
                                       anything -> DVI output,
nothing on DVI/monitor on HD15:        anything -> primary output,
                                       CRTC1 -> secondary output,
                                       anything -> DVI output,
analog monitor on DVI/nothing on HD15: CRTC1 -> primary output,
                                       anything -> secondary output,
                                       anything -> DVI output,
digital monitor on DVI/nothing on HD15:anything -> primary output,
                                       anything -> secondary output,
                                       CRTC1 -> DVI output,
analog monitor on DVI/monitor on HD15: CRTC1 -> primary output
                                       CRTC2 -> secondary output
                                       anything -> DVI output,
digital monitor on DVI/monitor on HD15:anything -> primary output,
                                       CRTC2 -> secondary output,
                                       CRTC1 -> DVI output,


As you can see, you can put CRTC2 to the secondary output only if
monitors are connected to both outputs (or at least if primary output
has monitor connected). If you'll put CRTC2 on secondary output
unconditionally, you do not support (only) analog monitor connected
to analog G550 output...

Moreover, user may want CRTC2 on primary output and CRTC1 on secondary
(if his first monitor is analog one). And you cannot make this
config default too, as it would not work with TV-Out: user would
have primary display on TV then, and it is probably not what user
had in the mind.

So I still think that CRTC1 on all three outputs is configuration
which satisfies most of the users.
                                                Petr Vandrovec
                                                

Re: G550DH + G450DH Framebuffer succes & directfb question.

[Mark H. <Mar...@xs...>]

Hi,


> How about a kernel parameter solution?
> I.e. your current setup is the default, but someone who specifies
> matrox:twoscreens
> on the kernel command line (or module parameter) gets the first
> framebuffer displayed on the first output, _and_ the second framebuffer
> displayed on  the second output.

I like this idea!
I don't need auto-detect of my devices, I already know which devices
are connected :-)

But I would like a more generic solution (since I have 2 matrox cards :-),
e.g. my current setup could be:
    matrox:out0=vga,out1=vga,out2=vga,out3=paltv
Or perhaps even a video mode per output could be specified as is now
done with the kernel 'video' parameter.
Would it be hard to implement such a paramater?

This way all my outputs can be set-up correctly right from the kernel
commandline, and I get the right output on the right screen from boot.
Would this also solve the problem where switching videomodes causes the
heads to both show crtc1 output?
Hmm, guess I have some tinkering to do again :-)

> We don't need to alter the driver for everybody, merely making an
> option. How about it?
Couldn't agree more :-)


Mark.

Re: G550DH + G450DH Framebuffer succes & directfb question.

[Helge H. <hel...@ai...>]

Petr Vandrovec wrote:

>On 19 May 04 at 11:10, Svetoslav Slavtchev wrote:
>  
>
>>>I'm considering patching it so it'll boot up with separate outputs instead
>>>of mirroring by default.  This should ideally be a kernel command
>>>line option, as the current default is useful for those with only one
>>>screen.  (But then, why get a G550 if you use one screen only . . .)
>>>      
>>>
>>Petr refused to help me on this issue,
>>do you have idea how to patch it ?
>>    
>>
>
>I have no idea what you are talking about...
>
>I sent you which values you should replace in the driver if you want
>mapping which is incompatible with BIOS, with Windows drivers, with XFree
>and with all singlehead configurations: Just replace output #1 source in the
>matroxfb_g450.c::matroxfb_g450_connect with CRTC2 instead of using CRTC1, 
>and you are done.
>
>-  ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC1;
>+  ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC2;
>
>
>But then do not complain that analog output described as PRIMARY in the
>matrox documentation displays CRTC2 and not CRTC1 (i.e. it brokes
>all analog singlehead configs and thus consider it vetoed for stock
>kernel).
>

How about a kernel parameter solution?
I.e. your current setup is the default, but someone who specifies
matrox:twoscreens 
on the kernel command line (or module parameter) gets the first framebuffer
displayed on the first output, _and_ the second framebuffer displayed on 
the second output.

This would not upset compatibility with default configurations, and
still allow booting with two independent screens for those
who have them. (And two independent terminals, when ruby is in
use also.)

We don't need to alter the driver for everybody, merely making an 
option. How about it? 

Helge Hafting

Re: G550DH + G450DH Framebuffer succes & directfb question.

[Svetoslav S. <sv...@gm...>]

> On 19 May 04 at 13:16, Svetoslav Slavtchev wrote:
> > 
> > and it would be nicer to not need matroxset in order
> > to get two independant fbcon on G550
> 
> It would need sensing card outputs to find which outputs have connected
> monitor and which do not, and as there is no doc...
>  

isn't it possible to simply assume that both outputs
have connected monitors ?
or does the driver need to retrive monitor data,
in order to setup properly ?

best,

svetljo

-- 
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info

Re: G550DH + G450DH Framebuffer succes & directfb question.

[Svetoslav S. <sv...@gm...>]

> On 19 May 04 at 13:16, Svetoslav Slavtchev wrote:
> > 
> > and it would be nicer to not need matroxset in order
> > to get two independant fbcon on G550
> 
> It would need sensing card outputs to find which outputs have connected
> monitor and which do not, and as there is no doc...

:(
 
> > i think the attached fix you send me some time ago
> > is still missing from vanilla 2.6.6-bk
> > care to submit it to Linus ?
> 
> I can try it. But I sent him missing memset() in matroxfb_maven
> (which causes crash, not just ill behavior, and it is obviously
> correct) three times and it still did not get through his email 
> filters. So it is probably time to try to submit my pending patches
> again. Last time I sent two one passed (ncpfs) and one was dropped
> (matroxfb max/max_t and memset), so maybe that sending patches in 
> batches increases probability that some will pass...

may be you should try sending them to Andrew 
for -mm and lkml.

i've heard Linus has the habit to simply delete
his inbox from time to time :-)

best,

svetljo

-- 
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info

Re: G550DH + G450DH Framebuffer succes & directfb question.

[Petr V. <VAN...@vc...>]

On 19 May 04 at 13:16, Svetoslav Slavtchev wrote:
> 
> and it would be nicer to not need matroxset in order
> to get two independant fbcon on G550

It would need sensing card outputs to find which outputs have connected
monitor and which do not, and as there is no doc...
 
> i think the attached fix you send me some time ago
> is still missing from vanilla 2.6.6-bk
> care to submit it to Linus ?

I can try it. But I sent him missing memset() in matroxfb_maven
(which causes crash, not just ill behavior, and it is obviously
correct) three times and it still did not get through his email 
filters. So it is probably time to try to submit my pending patches
again. Last time I sent two one passed (ncpfs) and one was dropped
(matroxfb max/max_t and memset), so maybe that sending patches in 
batches increases probability that some will pass...
                                                    Petr
                                                    

Re: G550DH + G450DH Framebuffer succes & directfb question.

[Svetoslav S. <sv...@gm...>]

> On 19 May 04 at 11:10, Svetoslav Slavtchev wrote:
> > > >
> > > I'm considering patching it so it'll boot up with separate outputs
> instead
> > > of mirroring by default.  This should ideally be a kernel command
> > > line option, as the current default is useful for those with only one
> > > screen.  (But then, why get a G550 if you use one screen only . . .)
> > 
> > Petr refused to help me on this issue,
> > do you have idea how to patch it ?
> 
> I have no idea what you are talking about...
> 
> I sent you 

you didn't 

> which values you should replace in the driver if you want
> mapping which is incompatible with BIOS, with Windows drivers, with XFree
> and with all singlehead configurations:

ok, but i want to use this incompatible config(and do use it)

and it would be nicer to not need matroxset in order
to get two independant fbcon on G550

> Just replace output #1 source in
> the
> matroxfb_g450.c::matroxfb_g450_connect with CRTC2 instead of using CRTC1, 
> and you are done.
> 
> -  ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC1;
> +  ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC2;

thanks a lot 
 
> But then do not complain that analog output described as PRIMARY in the
> matrox documentation displays CRTC2 and not CRTC1 (i.e. it brokes
> all analog singlehead configs and thus consider it vetoed for stock
> kernel).

i'm aware of this, and won't complain :-)

sorry if my previous mail sounded ofensive 

best,

svetljo

PS.

i think the attached fix you send me some time ago
is still missing from vanilla 2.6.6-bk
care to submit it to Linus ?

-- 
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/dsl

Re: G550DH + G450DH Framebuffer succes & directfb question.

[Petr V. <VAN...@vc...>]

On 19 May 04 at 11:10, Svetoslav Slavtchev wrote:
> > >
> > I'm considering patching it so it'll boot up with separate outputs instead
> > of mirroring by default.  This should ideally be a kernel command
> > line option, as the current default is useful for those with only one
> > screen.  (But then, why get a G550 if you use one screen only . . .)
> 
> Petr refused to help me on this issue,
> do you have idea how to patch it ?

I have no idea what you are talking about...

I sent you which values you should replace in the driver if you want
mapping which is incompatible with BIOS, with Windows drivers, with XFree
and with all singlehead configurations: Just replace output #1 source in the
matroxfb_g450.c::matroxfb_g450_connect with CRTC2 instead of using CRTC1, 
and you are done.

-  ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC1;
+  ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC2;


But then do not complain that analog output described as PRIMARY in the
matrox documentation displays CRTC2 and not CRTC1 (i.e. it brokes
all analog singlehead configs and thus consider it vetoed for stock
kernel).
                                                Best regards,
                                                    Petr Vandrovec
                                                    

Re: Patched Xfree86 4.3.0 in Debian

[Arne G. G. <ar...@li...>]

* Kjetil Kjernsmo
> OK, I know that there are at least one much used archive at 
> http://marc.theaimsgroup.com/?q=about#Add

There's one at http://news.gmane.org/gmane.linux.kernel.console which
is already operative.  It's only got a month's worth of articles yet,
though.


							Arne.

Re: G550DH + G450DH Framebuffer succes & directfb question.

[Svetoslav S. <sv...@gm...>]

> >
> >>I don't think the matroxset commands where 
> >>meant to be used with the ruby kernel.
> >>    
> >>
> >
> >there is nothing wrong with matroxset with ruby,
> >and it's the only way to separate the outputs 
> >of the two heads of G4x0DH or G550DH
> >else both fbdevs are mirrored :(
> >
> >does anyone have a better solution ?
> >  
> >
> I'm considering patching it so it'll boot up with separate outputs instead
> of mirroring by default.  This should ideally be a kernel command
> line option, as the current default is useful for those with only one
> screen.  (But then, why get a G550 if you use one screen only . . .)

Petr, refused to help me on this issue,
do you have idea how to patch it ?
IMHO if we figure out how to patch it,
it shouldn't be that hard to add the boot option

 
> >( 
> >of course it would be great to get independant fbcon 
> >without matroxset, but i'm not aware of such possibility
> >)
> >
> >  
> >
> 
> >>>P.S.
> >>>Did any of you have any success setting up dual independent
> >>>      
> >>>
> >>(accelerated) X
> >>    
> >>
> >>>servers on the G550? I'm very interested to see your XF86Config!
> >>>      
> >>>
> >>Me too. I like to give a demo of that.
> >>    
> >>
> >
> >IMO, this is only possible with the Matrox MMS series cards (G200 or
> G450)
> >two/ four heads by choice(pocket) , but they are really too
> >expensive
> >it's just that the hardware is missing
> >  
> >
> It is possible on a G550, _if_ you stick to 2D-accelearation only.
> Recipe:
> Install a ruby kernel, get it going with two independent consoles.
> Also connect two independent mice.
> Using framebuffers is one way to achieve this.
> 
> Install the accelerated X server.
> Run two such servers, on separate tty's so they will run simultaneously.
> Use two mostly identical XF86Config's, they should specify separate
> mice though. At least one of them must use a software mouse cursor,
> as the G550 only have one of these.
> No need for any prefbusid/isolatedevice because they run on the same
> card - and therefore they don't try to disable each other's cards.
> 
> This works in practice, the two servers didn't corrupt each others state,
> not even with a smp machine that really lets the two drivers execute
> simultaneously.
> 
> This recipe gives two independent accelerated xservers, using separate
> keyboards & mice.  Unfortunately they happen to run on the same
> screen, and tend to paint over each other all the time.
> I didn't go further than this, but believe you can use xinerama
> and simply tell the users to not abuse into each other's screens.
> Perhaps it is possible to do better than that - if anyone can
> figure out how to run accelerated X on the second head _only_.
> (First head only id trivial - it is the standard setup with xinerama off.)
> 
> Note that this didn't work well with 3D, last time I tried.
> One server using 3D blocks the other xserver 99% of the time, meaning
> the other user can't  work efficiently if the first user is using a game.
> Even 2D operations get blocked like this.  3D on both servers were
> impossible, even though two 3D clients on a single server works fine.

IMHO this is just a happy coinsidence,
and not a proper solution

> Things seems to happen fast on the DRI front, but I don't really
> expect this to work anytime soon.  Virtualizing the 3D accelerator
> will make this "easy", but the implied slowdown might not be
> desireable. 

yep, but IIRC DRI is still single card only :(

> Zoltán Böszörményi already showed dual 3D using two independent cards
> though, I believe that is the way to go for dual gaming.

i had it running on two PC's for a long time,
DRI + NVidia, and IIRC there must be a lot of
users with multiple NVidia cards
it's sort of sad that in order to have
multiple 3D accelerated users you MUST use NVidia
closed source drivers

best,

svetljo

-- 
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/dsl

Re: Patched Xfree86 4.3.0 in Debian

[Svetoslav S. <sv...@gm...>]

> Svetoslav Slavtchev wrote:
> 
> >>On mandag 17. mai 2004, 09:45, Aivils wrote:
> >>    
> >>
> >>>>s/PrefBusID/IsolateDevice/g
> >>>>right?
> >>>>        
> >>>>
> >>>Yep.
> >>>      
> >>>
> >>Cool! And thanks!
> >>    
> >>
> >
> >i'd say that the "SingleCard" would be a better choice,
> >no need for sed or perl :-)
> >  
> >
> I believe "device" is a better word than "card" in this context,
> it is possible for hw designers to put several devices on a
> card (or spread the device over several cards).  Today there
> is usually one device per card, but who knows
> what the future will bring.

you're right "device"  seems more reasonable,

and you seem to forget about the overpriced
Matrox MMS series with 2/4 chips/devices on a single card :-)

> > 
> >  
> >
> >>>>Then, I wondered about the HOWTO: Probably, we should now add some
> >>>>Debian-specific notes, now that people most likely can just use
> >>>>Sarge or Sid and get the X servers they need, but must use slightly
> >>>>different options than the rest of the world.
> >>>>        
> >>>>
> >
> >if you are talking about my howto,
> >i'd prefer the notes to be generic,
> >and i'll add them but first i've to find some time
> >and i've to finaly integrate your patch in my Xorg binaries
> >
> >  
> >
> >>>If end-user will start muptiple local xf86, then "IsolateDevice" is
> >>>not enough. Each xf86 open /dev/ttyXX , which one current is allowed
> >>>under Linus-tree kernel. Secondary xf86 become active when user press
> >>>Alt-F8 and primary xf86 goes spleep until user activate /dev/tty7.
> >>>
> >>>Multiple current /dev/ttyXX exist only in linux-ruby.
> >>>      
> >>>
> >>Yes, of course. Debian's approach to that is that you can create 
> >>kernel-patch-packages, which the user can trivially apply if s/he 
> >>chooses to build a kernel themself. For example, that's how Reiser4 is 
> >>supported in Debian: 
> >>http://packages.debian.org/unstable/devel/kernel-patch-2.6-reiser4
> >>
> >>I know Andreas has been thinking about making such a kernel-patch 
> >>package for ruby (and suggested I could do it, he'd sponsor it, but I 
> >>do not feel quite up to the task... :-) ). It would be really cool to 
> >>have the xf86 patches and the kernel-patch package. Meanwhile, there 
> >>are a lot more good tools available to compile a kernel, and people do 
> >>that more routinely, than to compile xf86, so it is a real advancement. 
> >>So, I just use Linus tree with (backstreet) ruby patches now. 
> >>
> >>
> >>    
> >>
> >>>>Unless you guys find Branden's
> >>>>changes reasonable, and adopt and recommend the above patch to
> >>>>others that want to get this stuff running, in which case the HOWTO
> >>>>could be changed to reflect the new names. So, what do you think
> >>>>about that?
> >>>>        
> >>>>
> >>>While single current TTY only allowed Branden have not a raw material
> >>>about what write how-to.
> >>>      
> >>>
> >>Uhm, I must admit I didn't fully parse that... :-) 
> >>    
> >>
> My guess: Branden can't write a proper howto on this, as he works
> with a standard (non-ruby) kernel that have the single-tty limitation.
> 
> >
> >mee too, 
> >Aivils, what did you had in your mind :-)
> >  
> >
> We live in a world with many different languages, with english being
> second or third or something for many of us.  I'm  happy I don't
> need to write in German. :-/

/* just kidding */
do you know Bulgarian may be :-)

best,
svetljo

-- 
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info

Re: Kernel summit/Desktop summit.

[Helge H. <hel...@ai...>]

James Simmons wrote:

>Hi folks!!!
>
>	For July 19 and 20th I will be attending the Desktop Summit as 
>well as the kernel summit. The kernel summit is unfortunely by 
>invitation only :-( but the desktop one is open to the public. To the 
>people that have worked hard on this project let me know if you want to go 
>to the desktop summit. If you don't have the money I will work something 
>out for you. I plan to give a demo of Ruby there!!!! So in the next few 
>weeks I'm going to set up a box to send to the conference. 
>
>My goals for the demo are to have a 4 desktop system. I like to get KDE 
>running on one desktop and Gnome on another. Then the other 2 heads would 
>be a Embedded JVM running and a regular console. 
>
Ideally set up so the session type (gnome, kde, regular,...) is
decided by login name rather than console number? Ability
to use any console for anything is great, it avoids the problem
of everybody wanting the "best" screen at home. :-)

Will you tell them about Zoltán Böszörményi's double 3D setup too? :-)

Helge Hafting

Re: G550DH + G450DH Framebuffer succes & directfb question.

[Helge H. <hel...@ai...>]

Svetoslav Slavtchev wrote:

>>>I managed to find a couple of matrox cards (G550 dual head AGP and a
>>>      
>>>
>>G450
>>    
>>
>>>dualhead PCI card), and decided to give it a go with ruby.
>>>I did not succeed in setting up a working dualhead X environment yet
>>>(although Xinerama works), but with framebuffer i have everything
>>>      
>>>
>>workingnow on kernel 2.6.5, even with modular matroxfb & fbcon drivers.
>>    
>>
>There are
>  
>
>>>still a few issues (I think Helge also mentioned some of them before):
>>>
>>>    * upon loading of the matroxfb drivers, all framebuffers show a
>>>      
>>>
>>garbled
>>    
>>
>>>      screen.
>>>      
>>>
>>This is a bug in the mainline kernel as well. The problem is VGA text 
>>console is not flushing it text buffers before the framebuffer driver 
>>takes over and then redraw the buffer. Another problem is some framebuffer
>>drivers call printk while initializing. When takeover_console is called 
>>the printk could be called while the hardware is in the in between state 
>>of vga text mode and graphics mode. The console layer wants to still print
>>something to the screen but the hardware is not ready for that.
>>
>>    
>>
>>>    * when loading fbcon, the garbled screen cleans up (mostly), but on
>>>      
>>>
>>the
>>    
>>
>>>      main console I see a big white rectangle. On none of the consoles
>>>      
>>>
>>I
>>    
>>
>>>      can see the login prompt, but it appears after pressing enter key
>>>      
>>>
>>:-)
>>
>>I have seen that before. The white rectangle is the size of the earlier 
>>console resolution you just toke over. I see this when I go from vgacon to
>>neofb with fbcon. The fbdev layer will most likely end up doing a memory 
>>clear out before taking over as a fix.
>>
>>    
>>
>>>    * when switching virtual console on the main console with F1-F6
>>>      
>>>
>>keys,
>>    
>>
>>>      the framebuffer setup is somehow messed up and so the main console
>>>      
>>>
>>is
>>    
>>
>>>      also shown on the second head. Rerunning the matroxset commands
>>>      
>>>
>>does
>>    
>>
>>>      not help, but after rerunning my 'reset_matrox' script which also
>>>      uses fbset to setup the framebuffers, everything works again.
>>>      
>>>
>>The matrox is a funny driver.
>>    
>>
>
>agree :(
>
>  
>
>>I don't think the matroxset commands where 
>>meant to be used with the ruby kernel.
>>    
>>
>
>there is nothing wrong with matroxset with ruby,
>and it's the only way to separate the outputs 
>of the two heads of G4x0DH or G550DH
>else both fbdevs are mirrored :(
>
>does anyone have a better solution ?
>  
>
I'm considering patching it so it'll boot up with separate outputs instead
of mirroring by default.  This should ideally be a kernel command
line option, as the current default is useful for those with only one
screen.  (But then, why get a G550 if you use one screen only . . .)

>( 
>of course it would be great to get independant fbcon 
>without matroxset, but i'm not aware of such possibility
>)
>
>  
>

>>>P.S.
>>>Did any of you have any success setting up dual independent
>>>      
>>>
>>(accelerated) X
>>    
>>
>>>servers on the G550? I'm very interested to see your XF86Config!
>>>      
>>>
>>Me too. I like to give a demo of that.
>>    
>>
>
>IMO, this is only possible with the Matrox MMS series cards (G200 or G450)
>two/ four heads by choice(pocket) , but they are really too
>expensive
>it's just that the hardware is missing
>  
>
It is possible on a G550, _if_ you stick to 2D-accelearation only.
Recipe:
Install a ruby kernel, get it going with two independent consoles.
Also connect two independent mice.
Using framebuffers is one way to achieve this.

Install the accelerated X server.
Run two such servers, on separate tty's so they will run simultaneously.
Use two mostly identical XF86Config's, they should specify separate
mice though. At least one of them must use a software mouse cursor,
as the G550 only have one of these.
No need for any prefbusid/isolatedevice because they run on the same
card - and therefore they don't try to disable each other's cards.

This works in practice, the two servers didn't corrupt each others state,
not even with a smp machine that really lets the two drivers execute
simultaneously.

This recipe gives two independent accelerated xservers, using separate
keyboards & mice.  Unfortunately they happen to run on the same
screen, and tend to paint over each other all the time.
I didn't go further than this, but believe you can use xinerama
and simply tell the users to not abuse into each other's screens.
Perhaps it is possible to do better than that - if anyone can
figure out how to run accelerated X on the second head _only_.
(First head only id trivial - it is the standard setup with xinerama off.)

Note that this didn't work well with 3D, last time I tried.
One server using 3D blocks the other xserver 99% of the time, meaning
the other user can't  work efficiently if the first user is using a game.
Even 2D operations get blocked like this.  3D on both servers were
impossible, even though two 3D clients on a single server works fine.

Things seems to happen fast on the DRI front, but I don't really
expect this to work anytime soon.  Virtualizing the 3D accelerator
will make this "easy", but the implied slowdown might not be
desireable. 

Zoltán Böszörményi already showed dual 3D using two independent cards
though, I believe that is the way to go for dual gaming.

Helge Hafting

Re: Patched Xfree86 4.3.0 in Debian

[Helge H. <hel...@ai...>]

Svetoslav Slavtchev wrote:

>>On mandag 17. mai 2004, 09:45, Aivils wrote:
>>    
>>
>>>>s/PrefBusID/IsolateDevice/g
>>>>right?
>>>>        
>>>>
>>>Yep.
>>>      
>>>
>>Cool! And thanks!
>>    
>>
>
>i'd say that the "SingleCard" would be a better choice,
>no need for sed or perl :-)
>  
>
I believe "device" is a better word than "card" in this context,
it is possible for hw designers to put several devices on a
card (or spread the device over several cards).  Today there
is usually one device per card, but who knows
what the future will bring.

> 
>  
>
>>>>Then, I wondered about the HOWTO: Probably, we should now add some
>>>>Debian-specific notes, now that people most likely can just use
>>>>Sarge or Sid and get the X servers they need, but must use slightly
>>>>different options than the rest of the world.
>>>>        
>>>>
>
>if you are talking about my howto,
>i'd prefer the notes to be generic,
>and i'll add them but first i've to find some time
>and i've to finaly integrate your patch in my Xorg binaries
>
>  
>
>>>If end-user will start muptiple local xf86, then "IsolateDevice" is
>>>not enough. Each xf86 open /dev/ttyXX , which one current is allowed
>>>under Linus-tree kernel. Secondary xf86 become active when user press
>>>Alt-F8 and primary xf86 goes spleep until user activate /dev/tty7.
>>>
>>>Multiple current /dev/ttyXX exist only in linux-ruby.
>>>      
>>>
>>Yes, of course. Debian's approach to that is that you can create 
>>kernel-patch-packages, which the user can trivially apply if s/he 
>>chooses to build a kernel themself. For example, that's how Reiser4 is 
>>supported in Debian: 
>>http://packages.debian.org/unstable/devel/kernel-patch-2.6-reiser4
>>
>>I know Andreas has been thinking about making such a kernel-patch 
>>package for ruby (and suggested I could do it, he'd sponsor it, but I 
>>do not feel quite up to the task... :-) ). It would be really cool to 
>>have the xf86 patches and the kernel-patch package. Meanwhile, there 
>>are a lot more good tools available to compile a kernel, and people do 
>>that more routinely, than to compile xf86, so it is a real advancement. 
>>So, I just use Linus tree with (backstreet) ruby patches now. 
>>
>>
>>    
>>
>>>>Unless you guys find Branden's
>>>>changes reasonable, and adopt and recommend the above patch to
>>>>others that want to get this stuff running, in which case the HOWTO
>>>>could be changed to reflect the new names. So, what do you think
>>>>about that?
>>>>        
>>>>
>>>While single current TTY only allowed Branden have not a raw material
>>>about what write how-to.
>>>      
>>>
>>Uhm, I must admit I didn't fully parse that... :-) 
>>    
>>
My guess: Branden can't write a proper howto on this, as he works
with a standard (non-ruby) kernel that have the single-tty limitation.

>
>mee too, 
>Aivils, what did you had in your mind :-)
>  
>
We live in a world with many different languages, with english being
second or third or something for many of us.  I'm  happy I don't
need to write in German. :-/

Helge Hafting

Re: Patched Xfree86 4.3.0 in Debian

[Svetoslav S. <sv...@gm...>]

> On onsdag 19. mai 2004, 00:52, Svetoslav Slavtchev wrote:
> > > On mandag 17. mai 2004, 09:45, Aivils wrote:
> > > > > s/PrefBusID/IsolateDevice/g
> > > > > right?
> > > >
> > > > Yep.
> > >
> > > Cool! And thanks!
> >
> > i'd say that the "SingleCard" would be a better choice,
> > no need for sed or perl :-)
> 
> Hehe, but you're saying that "SingleCard" is the option that replaces 
> the old "PrefBusID" in this patch?

it doesn't replace it, its an addition,
and IMO it's easier to use 
/* why specify BusID on 2 places,
 when it could be just one */
and it's the one that kept it's name in both patches :-)

> Well, the dual-head config didn't work when I installed the new 
> binaries, I guess there could be a reason for it... :-) 
can you explain a bit more?
what do you think is the reason?
if it's the new patch, i'll stay with prefbusid 
(and will have to add debian notes :( )
anyone using IsolateDevice Xserver successfully ?

> But then, Xinerama is nice too... :-)
> 
> > > > > Then, I wondered about the HOWTO: Probably, we should now add
> > > > > some Debian-specific notes, now that people most likely can
> > > > > just use Sarge or Sid and get the X servers they need, but must
> > > > > use slightly different options than the rest of the world.
> >
> > if you are talking about my howto,
> 
> Yup!

ok,
any other debian notes ?
other general notes ?

> > i'd prefer the notes to be generic,
> > and i'll add them but first i've to find some time
> > and i've to finaly integrate your patch in my Xorg binaries
> 
> OK, nice!
> 
> > > BTW, the linuxconsole-dev archives on Sourceforge seems dead...
> > > Nothing has been archived since March, that's why I thought the
> > > list was quiet...
> >
> > it's not just linux-console,
> > it's a lot of(if not all) sf.net project's ml's
> > it would be cool to have it archived on some other place too
> 
> OK, I know that there are at least one much used archive at 
> http://marc.theaimsgroup.com/?q=about#Add

that's my favourite :-)
would you add them ?

best,

svetljo

-- 
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/dsl

Re: Patched Xfree86 4.3.0 in Debian

[Kjetil K. <kj...@kj...>]

On onsdag 19. mai 2004, 00:52, Svetoslav Slavtchev wrote:
> > On mandag 17. mai 2004, 09:45, Aivils wrote:
> > > > s/PrefBusID/IsolateDevice/g
> > > > right?
> > >
> > > Yep.
> >
> > Cool! And thanks!
>
> i'd say that the "SingleCard" would be a better choice,
> no need for sed or perl :-)

Hehe, but you're saying that "SingleCard" is the option that replaces 
the old "PrefBusID" in this patch?

Well, the dual-head config didn't work when I installed the new 
binaries, I guess there could be a reason for it... :-) But then, 
Xinerama is nice too... :-)

> > > > Then, I wondered about the HOWTO: Probably, we should now add
> > > > some Debian-specific notes, now that people most likely can
> > > > just use Sarge or Sid and get the X servers they need, but must
> > > > use slightly different options than the rest of the world.
>
> if you are talking about my howto,

Yup!

> i'd prefer the notes to be generic,
> and i'll add them but first i've to find some time
> and i've to finaly integrate your patch in my Xorg binaries

OK, nice!

> > BTW, the linuxconsole-dev archives on Sourceforge seems dead...
> > Nothing has been archived since March, that's why I thought the
> > list was quiet...
>
> it's not just linux-console,
> it's a lot of(if not all) sf.net project's ml's
> it would be cool to have it archived on some other place too

OK, I know that there are at least one much used archive at 
http://marc.theaimsgroup.com/?q=about#Add

Cheers,

Kjetil
-- 
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
kj...@kj...  web...@sk...  ed...@le...
Homepage: http://www.kjetil.kjernsmo.net/        OpenPGP KeyID: 6A6A0BBC

Re: G550DH + G450DH Framebuffer succes & directfb question.

[Svetoslav S. <sv...@gm...>]

> 
> > I managed to find a couple of matrox cards (G550 dual head AGP and a
> G450
> > dualhead PCI card), and decided to give it a go with ruby.
> > I did not succeed in setting up a working dualhead X environment yet
> > (although Xinerama works), but with framebuffer i have everything
> workingnow on kernel 2.6.5, even with modular matroxfb & fbcon drivers.
There are
> > still a few issues (I think Helge also mentioned some of them before):
> > 
> >     * upon loading of the matroxfb drivers, all framebuffers show a
> garbled
> >       screen.
> 
> This is a bug in the mainline kernel as well. The problem is VGA text 
> console is not flushing it text buffers before the framebuffer driver 
> takes over and then redraw the buffer. Another problem is some framebuffer
> drivers call printk while initializing. When takeover_console is called 
> the printk could be called while the hardware is in the in between state 
> of vga text mode and graphics mode. The console layer wants to still print
> something to the screen but the hardware is not ready for that.
> 
> >     * when loading fbcon, the garbled screen cleans up (mostly), but on
> the
> >       main console I see a big white rectangle. On none of the consoles
> I
> >       can see the login prompt, but it appears after pressing enter key
> :-)
> 
> I have seen that before. The white rectangle is the size of the earlier 
> console resolution you just toke over. I see this when I go from vgacon to
> neofb with fbcon. The fbdev layer will most likely end up doing a memory 
> clear out before taking over as a fix.
> 
> >     * when switching virtual console on the main console with F1-F6
> keys,
> >       the framebuffer setup is somehow messed up and so the main console
> is
> >       also shown on the second head. Rerunning the matroxset commands
> does
> >       not help, but after rerunning my 'reset_matrox' script which also
> >       uses fbset to setup the framebuffers, everything works again.
> 
> The matrox is a funny driver.

agree :(

> I don't think the matroxset commands where 
> meant to be used with the ruby kernel.

there is nothing wrong with matroxset with ruby,
and it's the only way to separate the outputs 
of the two heads of G4x0DH or G550DH
else both fbdevs are mirrored :(

does anyone have a better solution ?

( 
of course it would be great to get independant fbcon 
without matroxset, but i'm not aware of such possibility
)

> > Since the framebuffers are working so well, I decided to try some
> DirectFB
> > applications (would like to run freevo or mythtv on my TV and try
> > the XDirectFB server), however, they don't seem to like ruby because I
> keep
> > getting the following error with every application I try to start:
> > 
> > (!) DirectFB/FBDev/vt: FBIOGET_CON2FBMAP failed!
> >     --> Inappropriate ioctl for device
> 
> Why is directfb call the console mapping function? That is really bad.
> 
> > Is there anything I can do to further investigate? Perhaps I can patch
> > ruby to add a dummy IOCTL or patch directfb in some way that the IOCTL
> is
> > not needed anymore?
> > Should I take this to the directfb mailinglist, or is it a ruby problem?
> 
> I would find out why directfb is playing with con2fb ioctl.
> 
> > The message reminds me of the old con2fbmap tool, which we don't need
> > anymore since ruby takes care of console to fb mapping :-)
>  
> > Well, I'm very impressed with ruby's current state on matroxfb, so
> > good work guys!
> > 
> > Mark.
> > 
> > 
> > P.S.
> > Did any of you have any success setting up dual independent
> (accelerated) X
> > servers on the G550? I'm very interested to see your XF86Config!
> 
> Me too. I like to give a demo of that.

IMO, this is only possible with the Matrox MMS series cards (G200 or G450)
two/ four heads by choice(pocket) , but they are really too
expensive
it's just that the hardware is missing

best,

svetljo

-- 
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/dsl

Re: G550DH + G450DH Framebuffer succes & directfb question.

[James S. <jsi...@in...>]

> I managed to find a couple of matrox cards (G550 dual head AGP and a G450
> dualhead PCI card), and decided to give it a go with ruby.
> I did not succeed in setting up a working dualhead X environment yet
> (although Xinerama works), but with framebuffer i have everything workingnow on kernel 2.6.5, even with modular matroxfb & fbcon drivers. There are
> still a few issues (I think Helge also mentioned some of them before):
> 
>     * upon loading of the matroxfb drivers, all framebuffers show a garbled
>       screen.

This is a bug in the mainline kernel as well. The problem is VGA text 
console is not flushing it text buffers before the framebuffer driver 
takes over and then redraw the buffer. Another problem is some framebuffer
drivers call printk while initializing. When takeover_console is called 
the printk could be called while the hardware is in the in between state 
of vga text mode and graphics mode. The console layer wants to still print 
something to the screen but the hardware is not ready for that.

>     * when loading fbcon, the garbled screen cleans up (mostly), but on the
>       main console I see a big white rectangle. On none of the consoles I
>       can see the login prompt, but it appears after pressing enter key :-)

I have seen that before. The white rectangle is the size of the earlier 
console resolution you just toke over. I see this when I go from vgacon to 
neofb with fbcon. The fbdev layer will most likely end up doing a memory 
clear out before taking over as a fix.

>     * when switching virtual console on the main console with F1-F6 keys,
>       the framebuffer setup is somehow messed up and so the main console is
>       also shown on the second head. Rerunning the matroxset commands does
>       not help, but after rerunning my 'reset_matrox' script which also
>       uses fbset to setup the framebuffers, everything works again.

The matrox is a funny driver. I don't think the matroxset commands where 
meant to be used with the ruby kernel.

> Since the framebuffers are working so well, I decided to try some DirectFB
> applications (would like to run freevo or mythtv on my TV and try
> the XDirectFB server), however, they don't seem to like ruby because I keep
> getting the following error with every application I try to start:
> 
> (!) DirectFB/FBDev/vt: FBIOGET_CON2FBMAP failed!
>     --> Inappropriate ioctl for device

Why is directfb call the console mapping function? That is really bad.

> Is there anything I can do to further investigate? Perhaps I can patch
> ruby to add a dummy IOCTL or patch directfb in some way that the IOCTL is
> not needed anymore?
> Should I take this to the directfb mailinglist, or is it a ruby problem?

I would find out why directfb is playing with con2fb ioctl.

> The message reminds me of the old con2fbmap tool, which we don't need
> anymore since ruby takes care of console to fb mapping :-)
 
> Well, I'm very impressed with ruby's current state on matroxfb, so
> good work guys!
> 
> Mark.
> 
> 
> P.S.
> Did any of you have any success setting up dual independent (accelerated) X
> servers on the G550? I'm very interested to see your XF86Config!

Me too. I like to give a demo of that.

Re: Patched Xfree86 4.3.0 in Debian

[Svetoslav S. <sv...@gm...>]

> On mandag 17. mai 2004, 09:45, Aivils wrote:
> > > s/PrefBusID/IsolateDevice/g
> > > right?
> >
> > Yep.
> 
> Cool! And thanks!

i'd say that the "SingleCard" would be a better choice,
no need for sed or perl :-)
 
> > > Then, I wondered about the HOWTO: Probably, we should now add some
> > > Debian-specific notes, now that people most likely can just use
> > > Sarge or Sid and get the X servers they need, but must use slightly
> > > different options than the rest of the world.

if you are talking about my howto,
i'd prefer the notes to be generic,
and i'll add them but first i've to find some time
and i've to finaly integrate your patch in my Xorg binaries

> >
> > If end-user will start muptiple local xf86, then "IsolateDevice" is
> > not enough. Each xf86 open /dev/ttyXX , which one current is allowed
> > under Linus-tree kernel. Secondary xf86 become active when user press
> > Alt-F8 and primary xf86 goes spleep until user activate /dev/tty7.
> >
> > Multiple current /dev/ttyXX exist only in linux-ruby.
> 
> Yes, of course. Debian's approach to that is that you can create 
> kernel-patch-packages, which the user can trivially apply if s/he 
> chooses to build a kernel themself. For example, that's how Reiser4 is 
> supported in Debian: 
> http://packages.debian.org/unstable/devel/kernel-patch-2.6-reiser4
> 
> I know Andreas has been thinking about making such a kernel-patch 
> package for ruby (and suggested I could do it, he'd sponsor it, but I 
> do not feel quite up to the task... :-) ). It would be really cool to 
> have the xf86 patches and the kernel-patch package. Meanwhile, there 
> are a lot more good tools available to compile a kernel, and people do 
> that more routinely, than to compile xf86, so it is a real advancement. 
> So, I just use Linus tree with (backstreet) ruby patches now. 
> 
> 
> > > Unless you guys find Branden's
> > > changes reasonable, and adopt and recommend the above patch to
> > > others that want to get this stuff running, in which case the HOWTO
> > > could be changed to reflect the new names. So, what do you think
> > > about that?
> >
> > While single current TTY only allowed Branden have not a raw material
> > about what write how-to.
> 
> Uhm, I must admit I didn't fully parse that... :-) 

mee too, 
Aivils, what did you had in your mind :-)

> BTW, the linuxconsole-dev archives on Sourceforge seems dead... Nothing 
> has been archived since March, that's why I thought the list was 
> quiet...

it's not just linux-console, 
it's a lot of(if not all) sf.net project's ml's
it would be cool to have it archived on some other place too
 
best,

svetljo

-- 
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info