Re: ruby-2.6.0-test3 updates

[Svetoslav S. <ga...@st...>]

Quoting Svetoslav Slavtchev <ga...@st...>: 
 
> Quoting James Simmons <jsi...@in...>:   
>    
> >    
> > > fb_con could make me to switch to 2.6,   
> > > but until it becomes real and or 2.6 gets more polished   
> >    
> > Alot of fixes are needed for the standardd fbdev layer. It is alomst    
> > there.   
> >    
> > > > TODO:   
> > > > dummy console command line parser to set up VC per VT.   
> > >    
> > > who needs more then one per dumb VT ?   
> > > what for ?   
> >    
> > Its standard to 64 VCs pre VT. For ruby we use 16 Vcs for VT. It makes    
> > take_over_console function properly as well.   
>    
> can you explain a bit more ?   
> MAX_NR_CONSOLES=63 because at 64 starts serial   
> MAX_NR_USER_CONSOLES=8 (ok at least in bruby & i think  ruby up to 2.5.6x)  
am sorry, my clock says 02:00 here :( 
> so how can we have 2,3,4 or more VT's   
each with 64 VC's 
 
> i thought that dumbcon is mostly temporaly solution for   
> bruby, until things are fixed for fbcon and one could then use a real VT 
with fbcon 
 
 
> VC's in ruby(and later std linux).   
> but how are usefull more VC's on a dumbcon ?   
>    
> why loose unused VC's on a dumbcon, when you need only one VC to start X on 
> it   
> in case they are a limited number MAX_NR_CONSOLES    
> and probably more VC's eat some system memmory,..    
>    
> > > and why again a hard limit ? MAX_DUMB_CONSOLES=16   
> > > which in the current situation could go up-to    
> > > MAX_CONSOLES - 1xVGAx8 = 55     
> >    
> > 16 is used because of VT_GETSTATE ioctl.    
>    
> wouldn't it be better to fix it :-)   
>    
> > > > /proc interface to manage console-input link (i use it).   
> > >    
> > > You use it with this patch or under 2.4 ?   
> > >    
> > > without this feature hotpluging/ cold-pluging will be really hard    
> >    
> > :-/   
> >    
> >    
> > > > xf86 /proc filter in the kernel to allow newbies start ruby for X.   
> > >    
> > > i really doubt it, that newbies will go to try ruby-2.6 soon,   
> > > currently may be only Debian unstable supports out of the box 2.6   
> > > and until more major distributions make the switch   
> > > (and Debian stable:) ), i think very few newbies    
> > > will try vanilla-2.6 (not to speak about ruby)    
> >    
> > True. This is more bleeding edge stuff anyways.   
> >     
> > > I'll check it out.   
> > >    
> > > i think it would be better first to polish 2.4 where the user base would  
>  
> > be   
> > > bigger, and release it to linuxconsole.sf.net ? more publicity ?   
> > > may be some words on the linuxconsole's web page about your work, and 
the 
>   
> > status   
> > > of bruby & ruby-2.6   
> > > may be even .rpms .debs of bruby    
> >    
> > I like to resurrect 2.4.X ruby again. It was pretty stable.    
> >    
> > > what will hapen if i boot with dumbcon=20 ?   
> > > how hard will be to backport the variable VC per VT to 2.4 ?   
> >    
> > I don't care for this idea. It could be messing when switching between on   
>  
> > VT display to another if they don't match up with the number VCs. I do    
> > understand where Alvis is getting at. What I like to see is VT console    
> > work with VT console. This way we could have a serial tty to login into   
>  
> > and still see printks on the screen. This would make the system much    
> > light. Prehaps struct vc_data default_mode could be the only VC in that   
>  
> > case. I have to play with that idea.   
> >    
>    
> one can not switch VC's on a dumbcon,   
> or at least i don't see a point in doing so,   
> but i would realy like to try 4,5,6 Matrox MMS G200/G450 in a single system  
>  
> which would mean 16-24 heads   
>    
> for a stand alone system this is probably impossible currently   
> i mean the system will crowl, but i think it shouldn't be a problem in 
> running    
> that much users in case the ruby box is used as LTSP client.   
>    
> and as currently there is no /proc interface for hotplging,  
> this will limit the system to ~7-8 users (MAX_DUMB_CONSOLE=16) in case usb  
> keyboards are used.  
> in bruby 4 users with usb keyboards if hotpluging is not used  
>   
> ( i wasn't aware of this limitation until i got a question from user )  
>   
> best,  
>   
> svetljo   
>  
>  
>  
> ------------------------------------------------------- 
> This sf.net email is sponsored by:ThinkGeek 
> Welcome to geek heaven. 
> http://thinkgeek.com/sf 
> _______________________________________________ 
> Linuxconsole-dev mailing list 
> Lin...@li... 
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev 
>  
 
 
--