linuxconsole-dev

ruby for recent 2.6.1 & 2.6.2-rcX kernels?

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

Hi,

Just out of curiosity, has anyone got a ruby patch for
recent 2.6.1-mmX or 2.6.2-rcX kernels?
The patch that I extracted using CVS / 2.6.0 doesn't
apply to recent kernels anymore :-(

My current 2.6.0 is working fine, so it is not urgent,
but I'm just curious how the more recent versions are
doing :-)
Any news on the framebuffer support yet? Last time I
tried was not very succesfull (GeForce2 MX400 AGP &
GeForce4 MX440 PCI cards).
Again, just out of curiosity, I'm not depending on the
feature :-)

Kind regards,
Mark.

Re: ruby for recent 2.6.1 & 2.6.2-rcX kernels?

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

> Hi,
> 
> Just out of curiosity, has anyone got a ruby patch for
> recent 2.6.1-mmX or 2.6.2-rcX kernels?
> The patch that I extracted using CVS / 2.6.0 doesn't
> apply to recent kernels anymore :-(

me wondering too :-)
Aivils is pretty quiet in the last month or so,
i checked yesterday the bk-tree and it was synced to 2.6.1rc1,
but it's missing most of the things added by Aivils to ruby-2.6 cvs
(hotpluging/ video-hack/ variable vc count) and i'm not sure
if it does boot 

i've some things in my head, but i can not find time
to get them on paper(ok actually on electronic paper :-)

so it might be a good idea to mention at least one of them

so 
i was thinking it would be a good idea to populate a bit
the file area on linuxconsole.sf.net
IMO it would be a good idea to provide a snapshot as patch
(may be including the other arch changes from the bk-tree)
and may be even a full tarball (prepatched vanilla 2.6. smth)

or may be two patches:
one ruby-2.6 cvs and a separate patch for the other arches

there is one more thing,
IMHO the instructions how to get ruby running
on linuxconsole.sf.net are so obsolated that they should be dropped
they have some value for bruby, but nothing related to ruby,

> My current 2.6.0 is working fine, so it is not urgent,
> but I'm just curious how the more recent versions are
> doing :-)
> Any news on the framebuffer support yet? Last time I
> tried was not very succesfull (GeForce2 MX400 AGP &
> GeForce4 MX440 PCI cards).
> Again, just out of curiosity, I'm not depending on the
> feature :-)

well i don't have luck with  my GeForce4 MX440 PCI (secondary),
even with current fbdev bk tree, it still reports 2Mb card memmory
(lspci returns 64Mb)
may be arround 2.6.3, 2.6.4 the fbdev changes will be merged in mainline
and the problems will start to get fixed


best,

svetljo

-- 
+++ GMX - die erste Adresse für Mail, Message, More +++
Bis 31.1.: TopMail + Digicam für nur 29 EUR http://www.gmx.net/topmail

Re: ruby for recent 2.6.1 & 2.6.2-rcX kernels?

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

> me wondering too :-)
> Aivils is pretty quiet in the last month or so,
> i checked yesterday the bk-tree and it was synced to 2.6.1rc1,
> but it's missing most of the things added by Aivils to ruby-2.6 cvs

> (hotpluging/ 

Hotplug is being reworked to work with sysfs which I have support for in 
my fbdev tree. I will be pushing that very shortly.

> video-hack/ 

With sysfs this can go away. In fact with the seperation of fbcon from 
fbdev you can instead, just build vgacon and a bunch of fbdev drivers. 
Loading the fbdev drivers, if module, or even if it is built in will not 
activate the graphics mode. Only if you do a set mode on /dev/fbX. You 
will see a much better system develope. 

> variable vc count) 

The only reason for this is to have many dummycons. With sysfs this can go 
away. Also this breaks some of the SysV console ioctls :-(

> and i'm not sure if it does boot 

vgacon works fine. The fbcon driver is broken but it could be fixed except 
that the fbcon layer will change alot in the next few weeks.

> so 
> i was thinking it would be a good idea to populate a bit
> the file area on linuxconsole.sf.net
> IMO it would be a good idea to provide a snapshot as patch
> (may be including the other arch changes from the bk-tree)
> and may be even a full tarball (prepatched vanilla 2.6. smth)
> 
> or may be two patches:
> one ruby-2.6 cvs and a separate patch for the other arches
> 
> there is one more thing,
> IMHO the instructions how to get ruby running
> on linuxconsole.sf.net are so obsolated that they should be dropped
> they have some value for bruby, but nothing related to ruby,

They are outdated. Sorry. We need to migrate the new stuff of Alviss to 
the web directory.

> > My current 2.6.0 is working fine, so it is not urgent,
> > but I'm just curious how the more recent versions are
> > doing :-)
> > Any news on the framebuffer support yet? Last time I
> > tried was not very succesfull (GeForce2 MX400 AGP &
> > GeForce4 MX440 PCI cards).
> > Again, just out of curiosity, I'm not depending on the
> > feature :-)

There is a nasty bug in the rivafb driver. I still haven't fixed that 
yet. 

> well i don't have luck with  my GeForce4 MX440 PCI (secondary),
> even with current fbdev bk tree, it still reports 2Mb card memmory
> (lspci returns 64Mb)
>
> may be arround 2.6.3, 2.6.4 the fbdev changes will be merged in mainline
> and the problems will start to get fixed

I plan on that.

Re: ruby for recent 2.6.1 & 2.6.2-rcX kernels?

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

> 
> > me wondering too :-)
> > Aivils is pretty quiet in the last month or so,
> > i checked yesterday the bk-tree and it was synced to 2.6.1rc1,
> > but it's missing most of the things added by Aivils to ruby-2.6 cvs
> 
> > (hotpluging/ 
> 
> Hotplug is being reworked to work with sysfs which I have support for in 
> my fbdev tree. I will be pushing that very shortly.

i wasn't clear 
what i ment was input /* keyboard */ configuration
using hotplug & /proc/bus/console/

how could this be done using sysfs ?

> > video-hack/ 
> 
> With sysfs this can go away. In fact with the seperation of fbcon from 
> fbdev you can instead, just build vgacon and a bunch of fbdev drivers. 
> Loading the fbdev drivers, if module, or even if it is built in will not 
> activate the graphics mode. Only if you do a set mode on /dev/fbX. You 
> will see a much better system develope. 

?
probably again didn't express myself clear
i ment the hack that tells the kernel to ignore
XFree pci/mem disable fuctions, so moe then one
X server can run at the same time

IIRC this was planed to be fixed by XFree
once ruby is merged upstream

how is sysfs related here ?
 
> > variable vc count) 
> 
> The only reason for this is to have many dummycons. With sysfs this can go

what do you mean by this ?
IMO we have a limit of 64 vc's,
if (the case with the bk tree) vc_count is fixed to 16
we have a maximum of 64/16 = 4 consoles (fb/dummy)
which IMO is pretty limiting 
( e.g. only 2 Matrox G200/ Gx50 DH or single G200/G4500 MMS QH)
whereas in combination with LTSP i could imagine a 10/16/20 headed box
which works relatively responsible

vc_count also gives you possiblity to limit the number of allocated vc's
for fb consoles (IIRC except the one that takes over vga)

if the maximum 64 is really a hardlimit, there should be a way 
to change vc_count in order to increase the number of consoles

and yes, there are already user(s) with 4 X servers running
( i know one of them :-) )

oh
and without /proc/bus/console keyboard configuration
this means only 2 displays/heads in case usb multimedia keyboards
are used

> away. Also this breaks some of the SysV console ioctls :-(

isn't it fixable ? how bad is it ?
i used to have a patch that makes config options of 
MAX_NR_USER_CONSOLES & MAX_DUMB_CONSOLES
before Aivlis implemented vc_count
 
> > and i'm not sure if it does boot 
> 
> vgacon works fine. The fbcon driver is broken but it could be fixed except
> 
> that the fbcon layer will change alot in the next few weeks.

does this mean that ruby will stay only linux-2.8/ 3.0 code
or do you plan to change the ABI in linux-2.6 ?

fbcon works in Aivils code,and it's pretty nice to
have two consoles using a single G550
 
> > so 
> > i was thinking it would be a good idea to populate a bit
> > the file area on linuxconsole.sf.net
> > IMO it would be a good idea to provide a snapshot as patch
> > (may be including the other arch changes from the bk-tree)
> > and may be even a full tarball (prepatched vanilla 2.6. smth)
> > 
> > or may be two patches:
> > one ruby-2.6 cvs and a separate patch for the other arches
> > 
> > there is one more thing,
> > IMHO the instructions how to get ruby running
> > on linuxconsole.sf.net are so obsolated that they should be dropped
> > they have some value for bruby, but nothing related to ruby,
> 
> They are outdated. Sorry. We need to migrate the new stuff of Alviss to 
> the web directory.
>

IIRC the only documentation on ruby-2.6  is to be found in
the mailing list archive
did i missed smth, can you point me to it ?

besides, IMO there is no need to explain how to compile
ruby-2.6 anymore, as there are no major differences compared
to a standard 2.6 kernel

> > > My current 2.6.0 is working fine, so it is not urgent,
> > > but I'm just curious how the more recent versions are
> > > doing :-)
> > > Any news on the framebuffer support yet? Last time I
> > > tried was not very succesfull (GeForce2 MX400 AGP &
> > > GeForce4 MX440 PCI cards).
> > > Again, just out of curiosity, I'm not depending on the
> > > feature :-)
> 
> There is a nasty bug in the rivafb driver. I still haven't fixed that 
> yet. 
> 
> > well i don't have luck with  my GeForce4 MX440 PCI (secondary),
> > even with current fbdev bk tree, it still reports 2Mb card memmory
> > (lspci returns 64Mb)
> >
> > may be arround 2.6.3, 2.6.4 the fbdev changes will be merged in mainline
> > and the problems will start to get fixed
> 
> I plan on that.

let's all hope Linus wil accept it :-)

best,

svetljo

-- 
GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...)
jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++

Re: ruby for recent 2.6.1 & 2.6.2-rcX kernels?

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

> > Hotplug is being reworked to work with sysfs which I have support for in 
> > my fbdev tree. I will be pushing that very shortly.
> 
> i wasn't clear 
> what i ment was input /* keyboard */ configuration
> using hotplug & /proc/bus/console/
> 
> how could this be done using sysfs ?

It can. Sysfs is a replacement for proc. So we need to create a sysfs 
attribute for the console. 

> probably again didn't express myself clear
> i ment the hack that tells the kernel to ignore
> XFree pci/mem disable fuctions, so more then one
> X server can run at the same time
> 
> IIRC this was planed to be fixed by XFree
> once ruby is merged upstream
> 
> how is sysfs related here ?

Because sysfs mounts the pci space and you can configure your pci 
hardware in userland :-) Try a 2.6.X kernel and do a 

mount -t sysfs sysfs /sys

You will see what I mean.

> > > variable vc count) 
> > 
> > The only reason for this is to have many dummycons. With sysfs this can go
> 
> what do you mean by this ?
> IMO we have a limit of 64 vc's,
> if (the case with the bk tree) vc_count is fixed to 16
> we have a maximum of 64/16 = 4 consoles (fb/dummy)
> which IMO is pretty limiting 
> ( e.g. only 2 Matrox G200/ Gx50 DH or single G200/G4500 MMS QH)
> whereas in combination with LTSP i could imagine a 10/16/20 headed box
> which works relatively responsible
>
> vc_count also gives you possiblity to limit the number of allocated vc's
> for fb consoles (IIRC except the one that takes over vga)
> 
> if the maximum 64 is really a hardlimit, there should be a way 
> to change vc_count in order to increase the number of consoles

I agree that 64 is way to small of a limit. We need to correct the tty layer 
to deal with this limit. In fact I think 64 heads is too small of a limit. 
I like to see it be dynamic. Unfortunely the problem is the serial ttys 
use the same major number range as VTs. How can we get around this? Well I 
have a idea on how to ask about this dealing with udev.

> and yes, there are already user(s) with 4 X servers running
> ( i know one of them :-) )
> 
> oh
> and without /proc/bus/console keyboard configuration
> this means only 2 displays/heads in case usb multimedia keyboards
> are used

Is this the USB keyboards showing up as two seperate devices problem.

> > away. Also this breaks some of the SysV console ioctls :-(
> 
> isn't it fixable ? how bad is it ?

Pretty yucky. Alot fo legacy software would break.

> does this mean that ruby will stay only linux-2.8/ 3.0 code
> or do you plan to change the ABI in linux-2.6 ?

Ruby will be 2.8/3.0 code.

> fbcon works in Aivils code,and it's pretty nice to
> have two consoles using a single G550

> IIRC the only documentation on ruby-2.6  is to be found in
> the mailing list archive
> did i missed smth, can you point me to it ?

Nope. We just need to piece everything together. 
 
> besides, IMO there is no need to explain how to compile
> ruby-2.6 anymore, as there are no major differences compared
> to a standard 2.6 kernel
 
That is true. The difference is very small now.

> let's all hope Linus wil accept it :-)

I spoke to linus about the patches. he will accept the fbdev patches as 
long as they are broken into smaller pieces.

Re: ruby for recent 2.6.1 & 2.6.2-rcX kernels?

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

Hi James,

at first a little bit rant may be :-)
<rant>
James, why don't you work step by step?
why don't you use a stable? working code base?
IMO you start a lot of new things before completing older work items.
Why don't you use the Aivils codebase, polish it up, and add new features
one by one, convert old features to new interfaces one by one, without
breaking stuff.
Currently (IMHO ) in your tree bugfixing, development/testing is done mostly
in your head (with no, or with verry small user testing ), if you were using
Aivils codebase (a working codebase) you would have a much wider
testing and i think this could help.
</rant> 

> > > Hotplug is being reworked to work with sysfs which I have support for
> in 
> > > my fbdev tree. I will be pushing that very shortly.
> > 
> > i wasn't clear 
> > what i ment was input /* keyboard */ configuration
> > using hotplug & /proc/bus/console/
> > 
> > how could this be done using sysfs ?
> 
> It can. Sysfs is a replacement for proc. So we need to create a sysfs 
> attribute for the console. 
> 
> > probably again didn't express myself clear
> > i ment the hack that tells the kernel to ignore
> > XFree pci/mem disable fuctions, so more then one
> > X server can run at the same time
> > 
> > IIRC this was planed to be fixed by XFree
> > once ruby is merged upstream
> > 
> > how is sysfs related here ?
> 
> Because sysfs mounts the pci space and you can configure your pci 
> hardware in userland :-) Try a 2.6.X kernel and do a 

i'm running 2.6 for the last 2 months or so
/* and i didn't  looked much in sysfs */

but do you mean that one can already use sysfs
to tel the kernel to ignore the mentioned XFree commands ?

> > > > variable vc count) 
> > > 
> > > The only reason for this is to have many dummycons. With sysfs this
> can go
> > 
> > what do you mean by this ?
> > IMO we have a limit of 64 vc's,
> > if (the case with the bk tree) vc_count is fixed to 16
> > we have a maximum of 64/16 = 4 consoles (fb/dummy)
> > which IMO is pretty limiting 
> > ( e.g. only 2 Matrox G200/ Gx50 DH or single G200/G4500 MMS QH)
> > whereas in combination with LTSP i could imagine a 10/16/20 headed box
> > which works relatively responsible
> >
> > vc_count also gives you possiblity to limit the number of allocated vc's
> > for fb consoles (IIRC except the one that takes over vga)
> > 
> > if the maximum 64 is really a hardlimit, there should be a way 
> > to change vc_count in order to increase the number of consoles
> 
> I agree that 64 is way to small of a limit. We need to correct the tty
> layer 
> to deal with this limit. In fact I think 64 heads is too small of a limit.
> 
> I like to see it be dynamic. Unfortunely the problem is the serial ttys 
> use the same major number range as VTs. How can we get around this? Well I
> 
> have a idea on how to ask about this dealing with udev.

you have in mind dinamic minor allocation  wjhich is supposed
to go in 2.7 ?

> > and yes, there are already user(s) with 4 X servers running
> > ( i know one of them :-) )
> > 
> > oh
> > and without /proc/bus/console keyboard configuration
> > this means only 2 displays/heads in case usb multimedia keyboards
> > are used
> 
> Is this the USB keyboards showing up as two seperate devices problem.

yes,
AFAIK multimedia keys are always using interface1
it would be great to remap all interface1 kbd's to the corresponding
interface0 kbd's, but just ignoring the interface1 kbd's when 
building vt - keyboard pairs would help too

we probably could also ignore ir-keyboards in the same way
just don't bind kbd's with PHYS == "pci-......." when building the pairs
 
> > > away. Also this breaks some of the SysV console ioctls :-(
> > 
> > isn't it fixable ? how bad is it ?
> 
> Pretty yucky. Alot fo legacy software would break.
> 
> > does this mean that ruby will stay only linux-2.8/ 3.0 code
> > or do you plan to change the ABI in linux-2.6 ?
> 
> Ruby will be 2.8/3.0 code.

> > let's all hope Linus wil accept it :-)
> 
> I spoke to linus about the patches. he will accept the fbdev patches as 
> long as they are broken into smaller pieces.

that's great :-)

best,
svetljo

-- 
GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...)
jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++

Re: ruby for recent 2.6.1 & 2.6.2-rcX kernels?

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

> Hi James,
> 
> at first a little bit rant may be :-)
> <rant>
> James, why don't you work step by step?
> why don't you use a stable? working code base?
> IMO you start a lot of new things before completing older work items.
> Why don't you use the Aivils codebase, polish it up, and add new features
> one by one, convert old features to new interfaces one by one, without
> breaking stuff.
> Currently (IMHO ) in your tree bugfixing, development/testing is done mostly
> in your head (with no, or with verry small user testing ), if you were using
> Aivils codebase (a working codebase) you would have a much wider
> testing and i think this could help.
> </rant> 

I played with both trees. The only reason for not syncing is because I 
knew the framebuffer code would change alot. Also I knew my fbdev tree 
would be different from the one linus would recieve. BTW I will start 
merging the fbdev over teh next several days.
 
> > Because sysfs mounts the pci space and you can configure your pci 
> > hardware in userland :-) Try a 2.6.X kernel and do a 
> 
> i'm running 2.6 for the last 2 months or so
> /* and i didn't  looked much in sysfs */
> 
> but do you mean that one can already use sysfs
> to tel the kernel to ignore the mentioned XFree commands ?

I have a feeling you can. I will talk to Patrick about how to do this.


> > > > > variable vc count) 
> > > > 
> > > > The only reason for this is to have many dummycons. With sysfs this
> > can go
> > > 
> > > what do you mean by this ?
> > > IMO we have a limit of 64 vc's,
> > > if (the case with the bk tree) vc_count is fixed to 16
> > > we have a maximum of 64/16 = 4 consoles (fb/dummy)
> > > which IMO is pretty limiting 
> > > ( e.g. only 2 Matrox G200/ Gx50 DH or single G200/G4500 MMS QH)
> > > whereas in combination with LTSP i could imagine a 10/16/20 headed box
> > > which works relatively responsible
> > >
> > > vc_count also gives you possiblity to limit the number of allocated vc's
> > > for fb consoles (IIRC except the one that takes over vga)
> > > 
> > > if the maximum 64 is really a hardlimit, there should be a way 
> > > to change vc_count in order to increase the number of consoles
> > 
> > I agree that 64 is way to small of a limit. We need to correct the tty
> > layer 
> > to deal with this limit. In fact I think 64 heads is too small of a limit.
> > 
> > I like to see it be dynamic. Unfortunely the problem is the serial ttys 
> > use the same major number range as VTs. How can we get around this? Well I
> > 
> > have a idea on how to ask about this dealing with udev.
> 
> you have in mind dinamic minor allocation  wjhich is supposed
> to go in 2.7 ?
> 
> > > and yes, there are already user(s) with 4 X servers running
> > > ( i know one of them :-) )
> > > 
> > > oh
> > > and without /proc/bus/console keyboard configuration
> > > this means only 2 displays/heads in case usb multimedia keyboards
> > > are used
> > 
> > Is this the USB keyboards showing up as two seperate devices problem.
> 
> yes,
> AFAIK multimedia keys are always using interface1
> it would be great to remap all interface1 kbd's to the corresponding
> interface0 kbd's, but just ignoring the interface1 kbd's when 
> building vt - keyboard pairs would help too
> 
> we probably could also ignore ir-keyboards in the same way
> just don't bind kbd's with PHYS == "pci-......." when building the pairs
>  
> > > > away. Also this breaks some of the SysV console ioctls :-(
> > > 
> > > isn't it fixable ? how bad is it ?
> > 
> > Pretty yucky. Alot fo legacy software would break.
> > 
> > > does this mean that ruby will stay only linux-2.8/ 3.0 code
> > > or do you plan to change the ABI in linux-2.6 ?
> > 
> > Ruby will be 2.8/3.0 code.
> 
> > > let's all hope Linus wil accept it :-)
> > 
> > I spoke to linus about the patches. he will accept the fbdev patches as 
> > long as they are broken into smaller pieces.
> 
> that's great :-)
> 
> best,
> svetljo
> 
> 

Re: ruby for recent 2.6.1 & 2.6.2-rcX kernels?

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

> Just out of curiosity, has anyone got a ruby patch for
> recent 2.6.1-mmX or 2.6.2-rcX kernels?
> The patch that I extracted using CVS / 2.6.0 doesn't
> apply to recent kernels anymore :-(

Nope. My tree is a bit different than Avliss tree. 

> My current 2.6.0 is working fine, so it is not urgent,
> but I'm just curious how the more recent versions are
> doing :-)
> Any news on the framebuffer support yet? Last time I
> tried was not very succesfull (GeForce2 MX400 AGP &
> GeForce4 MX440 PCI cards).
> Again, just out of curiosity, I'm not depending on the
> feature :-)

Alot of bug fixes is going on. Also the start of the merge of the newest 
framebuffer code will go in. I will add sysfs to the framebuffer which 
means we can get ride of the proc/pci bus hack :-)