linuxconsole-dev

Re: hijacled q

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

--- Aivils Stoss <ai...@un...> wrote:

> On Piektdiena, 9. Septembris 2005 13:23, you wrote:
> > Hi,
> >
> > I have an app that writes procfs status to
> keyboard
> > leds. Like:
> >
> > ...
> > ioctl ( ttys[i].fd, KDSETLED, savedleds|led );
> > ...
> >
> > WITH hijacled it does not work.
> >
> > WITHOUT hijacled it does work. And capslock
> numlock
> > and scrolllock still work on both keyboards.
> 
> But hijacled was intentionally created for that.
> hijacled isolate keyboards LED's from old /dev/ttyXX
> ioctl's. If Your 1st X/console don't use faketty,
> then code above works fine.
> 
> Normal kernel: You plug in 12 keyboards and press
> CapsLock on 1st - remaider 11 keyboards switch LED's
> as 1st one. You press key on twelfth and it goes to
> console.
> 
> hijacled: You plug in 12 keyboards and start single
> X
> on /dev/fttyXX as secondary head. Now You press
> CapsLock on 1st - remaider 10 keyboards switch LED's
> as 1st one, but twelfth was opened by X via faketty
> does not respond to 1st keyboard keypress. That
> twelfth
> is grabed by faketty. You press key on twelfth and
> it
> goes to X instead console. While /dev/fttyXX is not
> opened every keyboard is ordinary. Just close all
> /dev/fttyXX and check out Your code.

Good explanation.

In any case: with faketty like this:

lrwxrwxrwx  1 root root   10 2005-09-09 01:51
/dev/tty50 -> /dev/ftty1
lrwxrwxrwx  1 root root   10 2005-09-09 01:51
/dev/tty51 -> /dev/ftty0

and gdm running X1 to vt51 and X0 to vt7
(AGP TNT2 + MX-440 PCI)

and hijacled NOT running,

I can write to LEDs of tty1-7 and they function.
I can hit caps lock on both kbds and get the LED on.
But I cannot write to tty51 (cannot open...) nor to
tty50 (vc's don't switch).

With Ruby I could write to tty17 that X1 was running.

Hugo







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

Documentation

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

Early days

http://members.westnet.com.au/vanzeeland/Linux/configure_X.htm

comments suggestions, content submissions welcome...

J

Re: hijacled q

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

On Piektdiena, 9. Septembris 2005 13:23, you wrote:
> Hi,
>
> I have an app that writes procfs status to keyboard
> leds. Like:
>
> ...
> ioctl ( ttys[i].fd, KDSETLED, savedleds|led );
> ...
>
> WITH hijacled it does not work.
>
> WITHOUT hijacled it does work. And capslock numlock
> and scrolllock still work on both keyboards.

But hijacled was intentionally created for that.
hijacled isolate keyboards LED's from old /dev/ttyXX
ioctl's. If Your 1st X/console don't use faketty,
then code above works fine.

Normal kernel: You plug in 12 keyboards and press
CapsLock on 1st - remaider 11 keyboards switch LED's
as 1st one. You press key on twelfth and it goes to
console.

hijacled: You plug in 12 keyboards and start single X
on /dev/fttyXX as secondary head. Now You press
CapsLock on 1st - remaider 10 keyboards switch LED's
as 1st one, but twelfth was opened by X via faketty
does not respond to 1st keyboard keypress. That twelfth
is grabed by faketty. You press key on twelfth and it
goes to X instead console. While /dev/fttyXX is not
opened every keyboard is ordinary. Just close all
/dev/fttyXX and check out Your code.

Aivils 

hijacled q

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

Hi,

I have an app that writes procfs status to keyboard
leds. Like:

...
ioctl ( ttys[i].fd, KDSETLED, savedleds|led );
...

WITH hijacled it does not work.

WITHOUT hijacled it does work. And capslock numlock
and scrolllock still work on both keyboards.

Why is that?


Hugo




	
		
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/

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: Local multi-user PC

[Alexandre T. <ale...@in...>]

Em Seg, 2005-09-05 =C3=A0s 14:02 +0300, Aivils Stoss escreveu:
Hi Members,

I have packages of nvidia driver to download in my URL:=20
http://oraculo.insignesoftware.com/current/4.0/Einstein/CONTRIB/Alexandre/S=
RPMS/

[]'s
Alexandre

> On Ceturtdiena, 18. Augusts 2005 01:16, Avi Alkalay wrote:
> > Aivils, I'm having very bad problems with closed source nvidia driver f=
or a
> > TNT2. I'm using the correct version 6629. The screen gets dirty and the
> > mouse pointer looks bad and moves slow.
>=20
> At weekend i tried move my system to Mandriva 2005. Unfortunately You
> are right. kernel 2.6.11-12mdk and Xorg 6.8.2 + any Nvidia closed source
> driver cannot start up any Nvidia PCI card!!! :-( I tried multiple nvidia=
=20
> driver versions, but all without success. AGP card surely works alltimes.
>=20
> I fall back to 2.4.31-bruby + Nvidia 5336. I should recompile my 2.4.31
> because of struct kbd_repeat incompatibilty with X 6.8.2 . I cannot recal=
l
> how many years i used that nvidia 5336, but i will not buy new video.
> I have FX 5200 and TNT2M64 both PCI and FX440 AGP.
>=20
> Nvidia closed source GLX implementation makes me happy.
>=20
> Aivils Stoss
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
>=20
>=20

Re: INPUT: keyboard_tasklet - don't touch LED's of already grabed device

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

On Otrdiena, 6. Septembris 2005 14:57, Vojtech Pavlik wrote:
> On Tue, Sep 06, 2005 at 04:52:28AM -0700, Hugo Vanwoerkom wrote:
> > --- Aivils Stoss <ai...@un...> wrote:
> > > Hi, Vojtech!
> > >
> > > Recent kernels allow exclusive usage of input device
> > > when
> > > input device is grabed. keyboard_tasklet does not
> > > check
> > > device state and switch LED's of all keyboards.
> > > However
> > > grabed device may be use another LED steering code.
> > >
> > > This patch forbid keyboard_tasklet switch LED's of
> > > grabed devices.
> > >
> > > Aivils Stoss
> >
> > While trying this with 2.6.12 it gets a compilation
> > error. Not when you move the added statements after
> > the structure declaration.
> >
> > Is that me heading for them thar hills?
>
> The patch probably wasn't tested. ;)

How a soul who hates kernel compilation can test a patch?
Runtime modifcation:
http://www.ltn.lv/~aivils/files/hijackled-2.6.11-12mdk.tar.bz2

Aivils

--- linux-2.6.13/drivers/char/keyboard.c        2005-08-29 02:41:01.000000000 +0300
+++ linux-2.6.13/drivers/char/keyboard.c~       2005-09-06 15:32:28.000000000 +0300
@@ -896,16 +896,18 @@ static inline unsigned char getleds(void
 static void kbd_bh(unsigned long dummy)
 {
        struct list_head * node;
        unsigned char leds = getleds();

        if (leds != ledstate) {
                list_for_each(node,&kbd_handler.h_list) {
                        struct input_handle * handle = to_handle_h(node);
+                       if (handle->dev->grab)
+                               continue;
                        input_event(handle->dev, EV_LED, LED_SCROLLL, !!(leds & 0x01));
                        input_event(handle->dev, EV_LED, LED_NUML,    !!(leds & 0x02));
                        input_event(handle->dev, EV_LED, LED_CAPSL,   !!(leds & 0x04));
                        input_sync(handle->dev);
                }
        }

        ledstate = leds;

Re: INPUT: keyboard_tasklet - don't touch LED's of already grabed device

[Vojtech P. <vo...@su...>]

On Tue, Sep 06, 2005 at 04:52:28AM -0700, Hugo Vanwoerkom wrote:
> 
> 
> --- Aivils Stoss <ai...@un...> wrote:
> 
> > Hi, Vojtech!
> > 
> > Recent kernels allow exclusive usage of input device
> > when
> > input device is grabed. keyboard_tasklet does not
> > check
> > device state and switch LED's of all keyboards.
> > However
> > grabed device may be use another LED steering code.
> > 
> > This patch forbid keyboard_tasklet switch LED's of
> > grabed devices.
> > 
> > Aivils Stoss
> 
> 
> While trying this with 2.6.12 it gets a compilation
> error. Not when you move the added statements after
> the structure declaration.
> 
> Is that me heading for them thar hills?
 
The patch probably wasn't tested. ;)

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: INPUT: keyboard_tasklet - don't touch LED's of already grabed device

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

--- Aivils Stoss <ai...@un...> wrote:

> Hi, Vojtech!
> 
> Recent kernels allow exclusive usage of input device
> when
> input device is grabed. keyboard_tasklet does not
> check
> device state and switch LED's of all keyboards.
> However
> grabed device may be use another LED steering code.
> 
> This patch forbid keyboard_tasklet switch LED's of
> grabed devices.
> 
> Aivils Stoss


While trying this with 2.6.12 it gets a compilation
error. Not when you move the added statements after
the structure declaration.

Is that me heading for them thar hills?

Hugo

<snip patch>



	
		
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/

Re: Local multi-user PC

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

--- Avi Alkalay <avi...@gm...> wrote:

> I think the good driver for the cheap TNT2 is 7167.
> I had a lot of problem with 6629 and the previous
> drivers.
> Subsequent drivers 

like 7667 says that it cannot be used for "legacy
cards"

didn't work claiming TNT2 as an
> unsupported card, and 
> suggesting to use older drivers.
> 
> Regards,
> Avi
> 
> On 9/5/05, Hugo Vanwoerkom <hvw...@ya...>
> wrote:
> > 
> > 
> > 
> > --- Aivils Stoss <ai...@un...> wrote:
> > 
> > > On Ceturtdiena, 18. Augusts 2005 01:16, Avi
> Alkalay
> > > wrote:
> > > > Aivils, I'm having very bad problems with
> closed
> > > source nvidia driver for a
> > > > TNT2. I'm using the correct version 6629. The
> > > screen gets dirty and the
> > > > mouse pointer looks bad and moves slow.
> > >
> > 
> > I am running 7167 and have no problems:
> > AGP TNT2
> > PCI MX-440
> > Debian 4.3.0.dfsg.1-8 XFree86 server
> > 
> > Hugo
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
>
______________________________________________________
> > Click here to donate to the Hurricane Katrina
> relief effort.
> > http://store.yahoo.com/redcross-donate3/
> >
> 


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

INPUT: keyboard_tasklet - don't touch LED's of already grabed device

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

Hi, Vojtech!

Recent kernels allow exclusive usage of input device when
input device is grabed. keyboard_tasklet does not check
device state and switch LED's of all keyboards. However
grabed device may be use another LED steering code.

This patch forbid keyboard_tasklet switch LED's of
grabed devices.

Aivils Stoss

--- linux-2.6.13/drivers/char/keyboard.c        2005-08-29 02:41:01.000000000 +0300
+++ linux-2.6.13/drivers/char/keyboard.c~       2005-09-06 10:09:35.000000000 +0300
@@ -895,16 +895,18 @@ static inline unsigned char getleds(void

 static void kbd_bh(unsigned long dummy)
 {
        struct list_head * node;
        unsigned char leds = getleds();

        if (leds != ledstate) {
                list_for_each(node,&kbd_handler.h_list) {
+                       if (handle->dev->grab)
+                               continue;
                        struct input_handle * handle = to_handle_h(node);
                        input_event(handle->dev, EV_LED, LED_SCROLLL, !!(leds & 0x01));
                        input_event(handle->dev, EV_LED, LED_NUML,    !!(leds & 0x02));
                        input_event(handle->dev, EV_LED, LED_CAPSL,   !!(leds & 0x04));
                        input_sync(handle->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

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

looping X0 + faketty + recovery

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

Hi,

Faketty is only used for reference here, it had
nothing to do with the loop.

I don't know what sequence started X0 looping, but on
X only the mouse moved and Alt-Ctl-F1 did nothing.

Secondary monitor on VT51 was fine and showed X0
looping.

First I cancelled the X0 server, then I scheduled a
restart of gdm through crontab on the secondary
monitor. That recovered everything.

Debian Sarge 4.3.0.dfsg.1-8 XFree86 server
kernel patch 2.6.12-vz3 of James Van Zeeland
Nvidia 7167 closed source driver
Faketty and hijacled.

Hugo






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

Re: Local multi-user PC

[Avi A. <avi...@gm...>]

Any suggestions on how to configure gdm.conf, kdmrc and xorg.conf so I can=
=20
get login windows on each screen an X server is running ?

I'd like to have independent display manager's login screen on :0.0, :0.1, =
:
1.0, :1.1.

Thank you,
Avi

On 9/5/05, Avi Alkalay <avi...@gm...> wrote:
>=20
> I think the good driver for the cheap TNT2 is 7167.
> I had a lot of problem with 6629 and the previous drivers.
> Subsequent drivers didn't work claiming TNT2 as an unsupported card, and=
=20
> suggesting to use older drivers.
>=20
> Regards,
> Avi
>=20
> On 9/5/05, Hugo Vanwoerkom <hvw...@ya...> wrote:
> >=20
> >=20
> >=20
> > --- Aivils Stoss <ai...@un...> wrote:
> >=20
> > > On Ceturtdiena, 18. Augusts 2005 01:16, Avi Alkalay
> > > wrote:
> > > > Aivils, I'm having very bad problems with closed=20
> > > source nvidia driver for a
> > > > TNT2. I'm using the correct version 6629. The
> > > screen gets dirty and the
> > > > mouse pointer looks bad and moves slow.
> > >
> >=20
> > I am running 7167 and have no problems:=20
> > AGP TNT2
> > PCI MX-440
> > Debian 4.3.0.dfsg.1-8 XFree86 server
> >=20
> > Hugo
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > ______________________________________________________
> > Click here to donate to the Hurricane Katrina relief effort.=20
> > http://store.yahoo.com/redcross-donate3/
> >=20
>=20
>

Re: Local multi-user PC

[Avi A. <avi...@gm...>]

I think the good driver for the cheap TNT2 is 7167.
I had a lot of problem with 6629 and the previous drivers.
Subsequent drivers didn't work claiming TNT2 as an unsupported card, and=20
suggesting to use older drivers.

Regards,
Avi

On 9/5/05, Hugo Vanwoerkom <hvw...@ya...> wrote:
>=20
>=20
>=20
> --- Aivils Stoss <ai...@un...> wrote:
>=20
> > On Ceturtdiena, 18. Augusts 2005 01:16, Avi Alkalay
> > wrote:
> > > Aivils, I'm having very bad problems with closed
> > source nvidia driver for a
> > > TNT2. I'm using the correct version 6629. The
> > screen gets dirty and the
> > > mouse pointer looks bad and moves slow.
> >
>=20
> I am running 7167 and have no problems:
> AGP TNT2
> PCI MX-440
> Debian 4.3.0.dfsg.1-8 XFree86 server
>=20
> Hugo
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> ______________________________________________________
> Click here to donate to the Hurricane Katrina relief effort.
> http://store.yahoo.com/redcross-donate3/
>

Re: Local multi-user PC

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

--- Aivils Stoss <ai...@un...> wrote:

> On Ceturtdiena, 18. Augusts 2005 01:16, Avi Alkalay
> wrote:
> > Aivils, I'm having very bad problems with closed
> source nvidia driver for a
> > TNT2. I'm using the correct version 6629. The
> screen gets dirty and the
> > mouse pointer looks bad and moves slow.
> 

I am running 7167 and have no problems:
AGP TNT2
PCI MX-440
Debian 4.3.0.dfsg.1-8 XFree86 server

Hugo







	
		
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/

Re: Local multi-user PC

[Avi A. <avi...@gm...>]

Well, I tested many driver versions with TNT2 and it worked well with=20
version 7167, patched X.org <http://X.org> and a stock 2.6 kernel from RHEL=
=20
4.1 (the latest).
I had to make manual installations in some parts of NVidia.
Today I'll test this same drivers with GF2 MX400 cards.

Regards,
Avi

On 9/5/05, Aivils Stoss <ai...@un...> wrote:
>=20
> On Ceturtdiena, 18. Augusts 2005 01:16, Avi Alkalay wrote:
> > Aivils, I'm having very bad problems with closed source nvidia driver=
=20
> for a
> > TNT2. I'm using the correct version 6629. The screen gets dirty and the
> > mouse pointer looks bad and moves slow.
>=20
> At weekend i tried move my system to Mandriva 2005. Unfortunately You
> are right. kernel 2.6.11-12mdk and Xorg 6.8.2 + any Nvidia closed source
> driver cannot start up any Nvidia PCI card!!! :-( I tried multiple nvidia
> driver versions, but all without success. AGP card surely works alltimes.
>=20
> I fall back to 2.4.31-bruby + Nvidia 5336. I should recompile my 2.4.31
> because of struct kbd_repeat incompatibilty with X 6.8.2 . I cannot recal=
l
> how many years i used that nvidia 5336, but i will not buy new video.
> I have FX 5200 and TNT2M64 both PCI and FX440 AGP.
>=20
> Nvidia closed source GLX implementation makes me happy.
>=20
> Aivils Stoss
>

Re: Local multi-user PC

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

On Ceturtdiena, 18. Augusts 2005 01:16, Avi Alkalay wrote:
> Aivils, I'm having very bad problems with closed source nvidia driver for a
> TNT2. I'm using the correct version 6629. The screen gets dirty and the
> mouse pointer looks bad and moves slow.

At weekend i tried move my system to Mandriva 2005. Unfortunately You
are right. kernel 2.6.11-12mdk and Xorg 6.8.2 + any Nvidia closed source
driver cannot start up any Nvidia PCI card!!! :-( I tried multiple nvidia 
driver versions, but all without success. AGP card surely works alltimes.

I fall back to 2.4.31-bruby + Nvidia 5336. I should recompile my 2.4.31
because of struct kbd_repeat incompatibilty with X 6.8.2 . I cannot recall
how many years i used that nvidia 5336, but i will not buy new video.
I have FX 5200 and TNT2M64 both PCI and FX440 AGP.

Nvidia closed source GLX implementation makes me happy.

Aivils Stoss

Re: Assigning sound card to X display

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

On Otrdiena, 9. Augusts 2005 03:04, ludovic pollet wrote:
> Hello,
>
> I adressed the sound card issue with multiple X display.
>
> It is a little filesystem for fuse (http://fuse.sourceforge.net/).
> Basically, it provides a symlink which depends on the DISPLAY environment
> variable.
>
> When a process will open /dev/dsp, the symlink will resolve depending on
> the DISPLAY variable of the process. From there, it is easy to make process
> on first display open the first dsp, and so on...
>
> This should works for any program using OSS (this covers most unfriendly
> ones, like Mozilla plugin, OpenOffice or vmware, ...), or ALSA in emulation
> mode (for native mode, alsalib is our friend :-).
>
> Source and binary are available at http://www.nnx.com/~pludov/sessiond/
> It should work out of the box for Fedora core 3, (with fuse installed)...
>
> Any feedback is welcome !

That runs very nice under Mandriva 2005LE, 2.4.31-bruby , fuse-2.3.0, 3 sound 
cards 2 of them is oss and 1 is alsa. However games use /dev/sound/dsp. I add 
additional script in /etc/profile.d , which set up SDL and OpenAL sound 
libraries.

sound.sh

#SDL
SDL_PATH_DSP="/dev/dsp"
#SDL_AUDIODRIVER="oss"
export SDL_PATH_DSP

#OpenAL
echo '(define lin-dsp-path "/dev/dsp")' > $HOME/.openalrc


sessiond startup scrip deletes /dev/dsp* stuff and creates links from
/dev/sound/* , /dev/dsp* to /var/sessions/* . devfs is in use.

Aivils Stoss

faketty + 2.6.13

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

Hi,

Running with faketty + 2.6.13 had to make a change in
faketty: class_simple disappeared with this release.
Did I sign off on that change? ;-)

I include the change to now use class_device_create
and class_device_destroy.

Works great. But I like 2.6.12-vz3 of James Van
Zeeland and faketty better with the nicksched
scheduler. Works smoother in my case.

The test: run the CPU 100% with something.
Play music. Run a clock with a seconds tick. Switch
screens from X to fbcon. Should happen immediately and
the sound should stay whole, the ticks not elongated.

Zaphod scheduler did not do that, nicksched does.

Hugo


	
		
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/

Re: system hangs after starting second X

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

--- "Hajducik, Jozef (EXT)"
<Joz...@ic...> wrote:

> Hi,
> I have same problem as Andrej van der Zee
> But deference is that my system debian 3.1 and
> kernel 2.6.11 after
> starting second X server first one freeze in login
> phase.
> If I change order of servers there is same behavior.
> If I log out from
> second running server system freeze , I have to make
> hardware reset

You are running with Sarge and kernel 2.6.11 and what?
Ruby? Which one? And what videocards do you have?

Hugo















	
		
______________________________________________________
Click here to donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/

system hangs after starting second X

[Hajducik, J. \(EXT\) <Joz...@ic...>]

Hi,
I have same problem as Andrej van der Zee
But deference is that my system debian 3.1 and kernel 2.6.11 after
starting second X server first one freeze in login phase.
If I change order of servers there is same behavior. If I log out from
second running server system freeze , I have to make hardware reset


Jozef

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
> 

FakeTTy - Please explain

[yitzhak b. g. <yit...@ya...>]

I noticed recent postings dealing with FakeTTy, but
it's not clear to me what it is or how to implement
it. Can somebody please provide documentation.
Thank You,
Yitzhak Bar Geva

--- lin...@li...
wrote:

> Send Linuxconsole-dev mailing list submissions to
> 	lin...@li...
> 
> To subscribe or unsubscribe via the World Wide Web,
> visit
> 
>
https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> or, via email, send a message with subject or body
> 'help' to
> 	lin...@li...
> 
> You can reach the person managing the list at
> 	lin...@li...
> 
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of Linuxconsole-dev digest..."
> 
> > Today's Topics:
> 
>    1. Future of Ruby: head for the hills (Hugo
> Vanwoerkom)
>    2. Re: Future of Ruby: head for the hills (Erik
> Walthinsen)
> > Date: Sat, 3 Sep 2005 10:10:45 -0700 (PDT)
> From: Hugo Vanwoerkom <hvw...@ya...>
> Subject: Future of Ruby: head for the hills
> To: bruby <lin...@li...>
> 
> 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 
> 
> > Date: Sat, 03 Sep 2005 12:45:46 -0700
> From: Erik Walthinsen <om...@vc...>
> To: Hugo Vanwoerkom <hvw...@ya...>
> CC: bruby <lin...@li...>
> Subject: Re: Future of Ruby: head for the hills
> 
> 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.
> 
> 
> 
> > _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
>
https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> 
>