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.