linuxconsole-dev

Future of Ruby: head for the hills

[Hugo V. <hvw...@ya...>]

Hi,

Found a neat quote from  Vojtech Pavlik in
fa.linux.kernel (Sep 1, 7:23 am):

==========================================
> (When) Will there ever be native kernel (and maybe
XFree) support for
> multiple independent keyboards?

The kernel console is unlikely to ever going to have
that - noone is interested in changing the console
subsystem.

The current state of input device support in the
kernel, however, allows any userspace program to
access them independently, including keyboards.

That means multi-user X and possibly a userspace
console implementation (Jon Smirl is planning one) has
no barriers in the kernel input device implementation
keeping it from proceeding.

The problems with multiple VGA cards, etc, are much
harder to solve, though. 
==============================================

I don't know Jon Smirl, but Aivils of course already
has such a solution with Faketty, working very well,
thank you.

So head for the hills and while you are running hope
Aivils is running with you.

Hugo









__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Future of Ruby: head for the hills

[Erik W. <om...@vc...>]

Hugo Vanwoerkom wrote:
> The problems with multiple VGA cards, etc, are much
> harder to solve, though. 

Tell me about it.  3+ solid weeks and no go.

I've traced the problem with my system down to DPMS, where the Radeon
driver thinks it's waking up the display (confirmed with initial
instrumentation of the driver), but it never does.  Unfortunately the
hardware is being packed up in 1 hour and gets on the plane to Bolivia
at 7:15am tomorrow morning, so I just bought hardware for 4 more
separate computers that we'll try to find space for in our crates.

OTOH, I've been running the core machine with just one video card and X
server for the last few hours while I was "shopping", and came back to
an X display that wouldn't wake up either.  The only unusual setting in
the xorg.conf appears to be VGAAccess "false", which is required for the
multi-head configuration to work without the servers crushing each other.

I've just removed the VGAAccess option from the server and started it
up, we'll see if it goes to sleep permanently as well.  If so,
something's wrong with this particular combination of driver and card,
relative to DPMS.  If not, then I've narrowed the problem down a little
bit more, except that I don't see any obvious "VGA-class" operations in
the DPMS code, just normal Radeon register pokes.

Single-server multi-head (xinerama and not) seems to work just fine with
DPMS, but I haven't had much in the way of exhaustive testing, simply no
time at the moment.

Once I get back in 2 weeks I'll be either ordering cards or using ones
left behind (new mobos might have onboard video, haven't checked that
yet) and hammering as hard as I can on this problem.  This, and the
inability for the X server to do VGA BIOS initialization if SingleCard
is "true", seem to be the only issues remaining to getting multi-seat X
working, not counting all the misc configuration issues, and
complications with other perhipherals like sound etc.  Those come next.

I would welcome help from anyone who's interested, including the Ubuntu
multiseat guys, X and console coders, etc.  I think multi-seat systems,
if they can be made stable and easy to build, are going to be a huge
deal in less developed countries, due to cost, power, and space concerns.

Re: Future of Ruby: head for the hills

[James v. Z. <ja...@dv...>]

As yitzhak has noted, we need to start a new documentation project.

RIP ruby?

Re: faketty + hijacled

Since they are modules can we implement this as a kernel patch? Is there
any impediment to statically compiling these - faketty and hijacled into
kernel? 

I'm not clear on the text and/or frambuffer console capabilities? Can
we? Several text consoles with X and vt switching? Or is that expecting
too much? :-)

>From here this needs to be tested and documented. It certainly sounds
like a more effeicient approach than manhandling the console subsystem.

I will be testing shortly and shall endeavour to write a HOWTO document
as I go. I'll be testing and writing how-to under FC4, so we may need to
note distribution specific details.

Last rites on ruby?


> The problems with multiple VGA cards, etc, are much
> harder to solve, though. 

But far from insurmountable, I feel. I've had three and four consoles
operational with small issues. Right now things are looking much better.

The worst PCI cards are the ones with broken VGA-BIOS implementations, I
feel. If you have a card that insists on being primary video, it will
never work as a secondary card. If you allow it to be primary, however,
you may well be able to add a secondary card, as long as it is a more
compatible card. I was unable to bring more than two consoles online in
this configuration, however.

It may be worth looking for BIOS updates for your cards.

Mainboards can be a problem, too, generally intel ones, I've found;
every via, nV, or AMD chipset I've used with multi-console has behaved
quite well.

J


On Sun, 2005-09-04 at 03:10, Hugo Vanwoerkom wrote:
> Hi,
> 
> Found a neat quote from  Vojtech Pavlik in
> fa.linux.kernel (Sep 1, 7:23 am):
> 
> ==========================================
> > (When) Will there ever be native kernel (and maybe
> XFree) support for
> > multiple independent keyboards?
> 
> The kernel console is unlikely to ever going to have
> that - noone is interested in changing the console
> subsystem.
> 
> The current state of input device support in the
> kernel, however, allows any userspace program to
> access them independently, including keyboards.
> 
> That means multi-user X and possibly a userspace
> console implementation (Jon Smirl is planning one) has
> no barriers in the kernel input device implementation
> keeping it from proceeding.
> 
> The problems with multiple VGA cards, etc, are much
> harder to solve, though. 
> ==============================================
> 
> I don't know Jon Smirl, but Aivils of course already
> has such a solution with Faketty, working very well,
> thank you.
> 
> So head for the hills and while you are running hope
> Aivils is running with you.
> 
> Hugo
> 
> 
> 
> 
> 
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> 

Re: Future of Ruby: head for the hills

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

On Sv=E7tdiena, 4. Septembris 2005 13:51, James van Zeeland wrote:
> As yitzhak has noted, we need to start a new documentation project.
>
> RIP ruby?
>
> Re: faketty + hijacled
>
> Since they are modules can we implement this as a kernel patch? Is there
> any impediment to statically compiling these - faketty and hijacled into
> kernel?

No. hijacled is one line patch by default, but devopled for stock
precompilded kernel. faketty fit under same rule as evdev.

> I'm not clear on the text and/or frambuffer console capabilities? Can
> we? Several text consoles with X and vt switching? Or is that expecting
> too much? :-)

Not capable.

> From here this needs to be tested and documented. It certainly sounds
> like a more effeicient approach than manhandling the console subsystem.
>
> I will be testing shortly and shall endeavour to write a HOWTO document
> as I go. I'll be testing and writing how-to under FC4, so we may need to
> note distribution specific details.
>
> Last rites on ruby?

Who wants continue Zoltan's work ?

Aivils

Re: Future of Ruby: head for the hills

[Zoltan B. <zb...@fr...>]

Aivils Stoss =C3=ADrta:
> On Sv=C4=93tdiena, 4. Septembris 2005 13:51, James van Zeeland wrote:
>>Last rites on ruby?
>=20
>=20
> Who wants continue Zoltan's work ?

I am still around and reading the list from time to time.
I don't have too much time to work on Ruby at present
but I made slow progress.

I would like to make Ruby as small as possible, by using
the current in-kernel facilities, like the global vc_cons[]
and kbd_table[] arrays. I expect the core changes to be
under 100K, measured in uncompressed patch size.

This faketty is a novel idea, though. Great work!
This and Ruby can live together peacefully so independent
FB/VGA/MDA consoles may work side-by-side with plain graphic
console-less X servers.

Best regards,
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi

Re: Future of Ruby: head for the hills

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

On Sestdiena, 3. Septembris 2005 20:10, Hugo Vanwoerkom wrote:
> Hi,
>
> Found a neat quote from  Vojtech Pavlik in
> fa.linux.kernel (Sep 1, 7:23 am):
>
> ==========================================
>
> > (When) Will there ever be native kernel (and maybe
>
> XFree) support for
>
> > multiple independent keyboards?
>
> The kernel console is unlikely to ever going to have
> that - noone is interested in changing the console
> subsystem.

No Linux console experts at linuxconsole.sf.net. That's true.
None of ruby versions are 100% compatible with VT100.
IHMO because of carelessnes of me and other developers. Who
wants check out these 1001 features?

Most nearest VT100 must be Zoltan's ruby-mm tree. Zoltan reject
old ruby code and put vt->foo instead foo manualy into -mm
tree. i didn't know how wide Zoltan test VT100 compatibility.

> The current state of input device support in the
> kernel, however, allows any userspace program to
> access them independently, including keyboards.
>
> That means multi-user X and possibly a userspace
> console implementation (Jon Smirl is planning one) has
> no barriers in the kernel input device implementation
> keeping it from proceeding.

faketty is competitor only. Since year 2003 Debian and
You too have evdev input drivers for XFree and Xorg, mouse
and keyboard supported.

> The problems with multiple VGA cards, etc, are much
> harder to solve, though.
> ==============================================

Up-to-date video cards show up this trouble very very
rarely. I mean Nvidia.

> I don't know Jon Smirl, but Aivils of course already
> has such a solution with Faketty, working very well,
> thank you.

faketty just coocked.

Aivils
> So head for the hills and while you are running hope
> Aivils is running with you.