Re: ruby-2.6.0-test3 updates

[Aivils S. <Aiv...@un...>]

>> 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.

fb_con is abstract layer now. Have You spare time to rewrite it
for single console under ruby ?
May VGA and any fb runs simultaneous?
Init fb VIDEOBIOS-less secondary adapters corectly?
libint10 is very higly polished under xf86, but i dont know
how about fbdev.

>> > 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.

dummy console nobody take over. I split dummy init in two parts.
1st boot time with MAX_NR_USER_CONSOLES and additional dummy for
xf86 servers.

>> 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.

Seems i set up 2 VCs per VT for additional dummy not early boot.

>> > /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
>
>:-/

This /proc interface runs under 2.4 since DEC-2002

>> > 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.

Ok. Very skilled users can test linux-ruby without recompiling xf86
of their distro. At least 2 pci video adapters runs flawless with
kernel filter only under stock xf86.

>> 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.

It is live around the world. (user_count>10 may be)
http://startx.times.lv/bruby-2.4.22-20030910.diff.bz2

>> 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.

variable VCs per VT is needed for additional dummy console. Some furious
users of fbdev uses 24 VCs.


Aivils Stoss