linuxconsole-dev

Re: ruby-2.6.0-test3 updates

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

>>
>> BROKEN: MDA console, fb_con.
>
>MDA should be easy to fix. Fbcon needs alot of work.

How about fbcon which uses only one VT as VGA ?

>> Power management of console lead oops - commented out.
>
>Yeap. I haven't figured out what the author of that code wanted to do.

I understan my mistake. i place pm_register in early boot time.

>> UNKNOWN: PC mainboard speaker and keyboard beeper.
>
>Shoudl work. I managed to get the speaker from oopings. Now it just
>doesn't work :-/

Under 2.4 speaker take aditional VT.

>> TODO:
>> dummy console command line parser to set up VC per VT.
>
>Ug. That has to be a fixed number. The problem is in vt_ioctl.c.
>For the case VT_GETSTATE it uses a short which means it scans for 16 VCs.
>It returns which VCs are in use. You could limit the amount of VCs but you
>can never have more than 16. Do we really want to have variable number
>VCs per VT?

Seems VCs should be in 2 between 16. 16 allow only 4 VT which is to few
for USB two interface keyboars, which takes two VT per each. I mean 16 for
real console with hardware output and 2 for dummy. VCs per VT count must
set up  in console init routine and this count remain fixed all console
lifetime. I do not mean runtime variable count of VCs per VT. This is done.

>Now what would be useful is controlling the number of VTs
>created.

vt_map_display() return NULL for redundant consoles - so reject it. This
one limit count of REALTERMINAL.

>Of course we end up hitting the 64 bit limit because the serial
>TTYs use 64 and up. This is something we will have to resolve somehow. Not
>a easy solution.
>
>> /proc interface to manage console-input link (i use it).
>
>Great. Eventually we can shift that to sysfs.

i check out it under 2.6 and then commit.

>> @@ -234,7 +234,7 @@ static void update_user_maps(struct vc_d
>>      struct uni_pagedir *p, *q = NULL;
>>      int i;
>>
>> -    for (i = 0; i < MAX_NR_USER_CONSOLES; i++) {
>> +    for (i = 0; i < vc->display_fg->vc_count; i++) {
>>           struct vc_data *tmp = vc->display_fg->vc_cons[i];
>
>Because of VT_GETSTATE we are stuck with MAX_NR_USER_CONSOLES. Now
>selecting how many VTs we can create would be useful.

we need special ioctl. VT_GETSTATE don't care how many VCs has a
REALTERMINAL.

IMHO we should change terminology. All linus tree kernel ioctl-s return
information about single REALTERMINAL, which has noname, because it is
a one. Under ruby You create vt_struct which contain information about
current REALTERMINAL. I use REALTERMINAL , because this is a union of
real-output-device and real-input-device, so we lost virtuality. Of
course this is not real teletypewriter just emulator. You by yourself
design all ioctl-s against current REALTERMINAL. VT_GETSTATE return info
about bunch of VCs of current REALTERMINAL.
I write this because very hard understand about what is a talkshow.
I suggest rename vt_struct to rt_struct and use anyplace abbreviation
rt. This one allow more easy explaining how to linux-ruby works.
And eliminate misunderstanding VT,VC and unnamed REALTERMINAL.

>I assume you are
>doing this so you can more than one dummycon registered correct?

Yes. I will use multiple dummy consoles with small VCs count.

>> +++ ruby-2.6.0-test3/drivers/char/decvte.c    2003-09-11
13:44:36.000000000
>> +0100
>> @@ -513,10 +513,10 @@ static void set_mode(struct vc_data *vc,
>>                switch (par[i]) {
>>                case 1:   /* DECCKM - Cursor keys mode */
>>                     if (on_off)
>> -                        set_kbd_mode(vc->kbd_table,
>> +                        set_kbd_mode(&vc->kbd_table,
>>                                    VC_CKMODE);
>
>> -static inline int get_kbd_mode(struct kbd_struct kbd, int flag)
>> +static inline int get_kbd_mode(struct kbd_struct * kbd, int flag)
>>  {
>> -    return ((kbd.modeflags >> flag) & 1);
>> +    return ((kbd->modeflags >> flag) & 1);
>>  }
>
>This is a performance killer. That was mistake in the 2.4.X tree. I can
>reverse that.

???????????????????????????????????????????????????????????????????????????
static inline void set_kbd_mode(struct kbd_struct kbd, int flag)
{
     kbd.modeflags |= 1 << flag;
}
???????????????????????????????????????????????????????????????????????????
IMHO this piece of code should not contain any program under any platform.
i allways wondering how You can do so great, big work without PC. Do You
work for
Pentagon, hangar 18, floor -24 ? %-)


Aivils Stoss

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

Re: ruby-2.6.0-test3 updates

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

Quoting Aivils Stoss <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

my question was about 2.6 :-)
it was on your to do list, but you also wrote "i use it"
so if you use it, why is it on the todo list ?

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

:)

or in case using MDK or Debian install packaged binaries
:)

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

:)
hm i never got ruby-2.4 runing, but bruby worked always :)
 

i had questions from 6-7 users, and at least 6 :) got it up and running
2 users with 3 displays(on 2-3 PC's),
the rest 2 displays but this is still TOOOO FEW :(


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

if we talk for graphic cards in serial production( ie from the shop)
it's not nessecary to be fbdev 
(and with fbdev it will be probably harder i think)

there quite a lot mainboards with 6 PCI + 1AGP slots
if you get several Matrox MMS cards, 
each with 4 heads(and chips with different BusID)
then you even can use the mga driver (acceleration, XV, ...)
but currently DRI actually doesn't work with more then one card :(

and i never could test even with single card cause they are pretty exspensive

are there any other cards with similar configuration ?

best,

svetljo

Re: ruby-2.6.0-test3 updates

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

>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
>VC's in ruby(and later std linux).

dummy is stable solution, because gonna smart :)
Users (me to) like xf86. Users (me to) like GLX accelerated xf86.
xf86 mostly initialize secondary video adapters pefect.
Posible PPC users (none known) may start ruby right now with dummy console
only.

>but how are usefull more VC's on a dumbcon ?

Seems VC's remain unused.

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

In my end 3 users which runs only (xchat,web chat,xmms)x3 may take 90% of
CPU
Athlon 1600+.

Aivils Stoss