linuxconsole-dev

Re: [ANNOUNCE] Synced with 2.4.6

[James S. <jsi...@tr...>]

> Well, not quite. First I still have some minor stuff to let it compile 
> successfully, second, I cannot test it, cause neither aty128fb.c nor offb.c 
> have been converted to the new console code yet. 

I have a partial offb.c driver ported over. The problem is I haven't
written a generic software image drawer for teh font stuff. The current
one is broken :-( I will start working on tonight. We really need it.
As for the ATI 128 driver. Well since we removed the console lock we can 
use the CCE engine of the card :-) Basically the driver will be rewritten
from scratch. The only thing their is I will have to move the agpo code
into video or something to ensure agp is initialized first.

> What may need work is the PS2 support on PREP and CHRP based machines, but 
> this is no big deal either.

Same with the mips platform. Minior tweaks mainly to deal with io region
space and what the irq number is. I know on mips it various alot.

Re: [ANNOUNCE] Synced with 2.4.6

[Franz S. <Fra...@la...>]

On Sunday 08 July 2001 20:28, James Simmons wrote:
> I just finished the finally syncing with Linus 2.4.6 tree and Russell
> kings 2.4.6-rmk1 tree. I tested both and they work :-) The tree also
> should work with the latest PPC tree thanks to Frank Sirl.

Well, not quite. First I still have some minor stuff to let it compile 
successfully, second, I cannot test it, cause neither aty128fb.c nor offb.c 
have been converted to the new console code yet. But I don't expect serious 
problems in the input drivers, as most parts of the code are already in 2.4. 
What may need work is the PS2 support on PREP and CHRP based machines, but 
this is no big deal either.

Franz.

[ANNOUNCE] Synced with 2.4.6

[James S. <jsi...@tr...>]

I just finished the finally syncing with Linus 2.4.6 tree and Russell
kings 2.4.6-rmk1 tree. I tested both and they work :-) The tree also
should work with the latest PPC tree thanks to Frank Sirl. 

Full m68k support.

[James S. <jsi...@tr...>]

Do you know who know the atari and hp300 input hardware (keyboard,
mice, joysticks) well so we can port the drivers to the input layer for
ruby. I really like to wrap up support for this platform.

synaptics touchpad not working with 2.4.x (fwd)

[James S. <jsi...@tr...>]

Does the i8042 drivers we have support this device?

---------- Forwarded message ----------
Date: Sun, 8 Jul 2001 22:49:30 +1000
From: CaT <ca...@zi...>
To: lin...@vg...
Subject: synaptics touchpad not working with 2.4.x

I;ve had this with 2.4.0 but have just tried with 2.4.6ac2 and still
have it.

Under 2.2.x the touchpad works like a dream. Under 2.4.x it stutters,
freezes and so on. Did something about /dec/psaux change between 2.2.x
and 2.4.x? Will I need to recompile glibc and/or gpm?

if I cat /dev/psaux I get data flowing through but gpm stays frozen. :/

Hope someone can help as, now that ext3 is being well and truly ported 
to 2.4.x, this is the last stumbling block for me having 2.4.x on
my laptop.

gpm options: /usr/sbin/gpm -m /dev/psaux -t synps2 -Rmsc -2
glibc: 2.1.3 compiled for 2.2.x

-- 
CaT (ca...@zi...)		*** Jenna has joined the channel.
				<cat> speaking of mental giants..
				<Jenna> me, a giant, bullshit
				<Jenna> And i'm not mental
					- An IRC session, 20/12/2000

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj...@vg...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: New member on this list

[James S. <jsi...@tr...>]

> As a start, I would like to contribute a device driver that allows to use
> Handykey's Twiddler (see http://www.handykey.com/) as a joystick. Please
> advice how I should proceed; shall I send the sources to the list or to
> someone else via private email?

More supprot for more wearable devices. Cool. Can you post the code to the
list. We like to get a look at it, try it out, and then commit it.

> PS: It took me a while to come across this list; since the Linux Console
> Project page at http://linuxconsole.sourceforge.net/ and Vojtech's pages
> at http://www.suse.cz/development/input/ haven't been updated for a
> long time, and the page http://sourceforge.net/projects/linuxconsole/
> doesn't look busy either (no news, no released files, no activity in
> the public forum), my impression was that the development had stalled.

We are very active. Its just we have no web designer working on our web
pages. All devleopement discussion is done on this list. All the code is
in CVS. If you look at the active of CVS you will see we are very busy.
Thanks to Franz Sirl we recently got proper a PowerPC port. A mips port is
under way.

Re: Handling beep

[James S. <jsi...@tr...>]

> We need a separate driver. We should be able to beep even with just a
> USB keyboard (and no AT keyboard driver inside the kernel).

Your right. I will add it today as well as the KDKBDREP. 

New member on this list

[Arndt S. <ab...@sr...>]

Hi folks,

my name is Arndt, and I am a new subscriber to the Linux console project
mailing list. The main reason why I am here is input devices; I have a lot
of different stuff (mice, trackballs, touchpads, keyboards, gamepads etc)
and would like to help getting them better supported under Linux.

As a start, I would like to contribute a device driver that allows to use
Handykey's Twiddler (see http://www.handykey.com/) as a joystick. Please
advice how I should proceed; shall I send the sources to the list or to
someone else via private email?

Thanks & CU,
Arndt

PS: It took me a while to come across this list; since the Linux Console
Project page at http://linuxconsole.sourceforge.net/ and Vojtech's pages
at http://www.suse.cz/development/input/ haven't been updated for a
long time, and the page http://sourceforge.net/projects/linuxconsole/
doesn't look busy either (no news, no released files, no activity in
the public forum), my impression was that the development had stalled.

Perhaps some actions are required to improve the public awareness ;-)

-- 
Arndt Schoenewald <ab...@sr...>
Ostenhellweg 31, 44135 Dortmund, Germany
Tel: +49 231 556075

Re: Handling beep

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

On Sun, Jul 01, 2001 at 07:23:34AM -0700, James Simmons wrote:
> 
>    A question on how to approach this problem. The input api has the
> ablity to send EV_SND events to a input device. Now I like to impliment
> this for the console system via kd_mksound. At present only the sun
> keyboard supports injecting sound which is apart of the keyboard driver.
> For the ix86 platform we have the PC speaker. Now the PC speaker is apart
> of the region the i8042 chipset uses but has nothing to do with the PS/2
> keyboard or mouse.
>    The question is should the beeper be a seperate device and we have a
> hook for it in the console system or do we make it apart of the keyboard
> driver and use the keyboards hook?

We need a separate driver. We should be able to beep even with just a
USB keyboard (and no AT keyboard driver inside the kernel).

-- 
Vojtech Pavlik
SuSE Labs

Re: EV_ABS and values

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

On Thu, Jul 05, 2001 at 01:45:39PM -0700, James Simmons wrote:

> I have a question. For touchscreens or any absolute value devices does the
> origin (0,0) starts at the "upper left" corner of the device?

Yes.

-- 
Vojtech Pavlik
SuSE Labs

EV_ABS and values

[James S. <jsi...@tr...>]

I have a question. For touchscreens or any absolute value devices does the
origin (0,0) starts at the "upper left" corner of the device?

Re: linux 2.5 vs. ruby

[James S. <jsi...@tr...>]

> what is the status of the ruby CVS (input layer part) vs. linux 2.5? Will 
> we be integrated starting from 2.5.0?

That is the plan. At first mostly new drivers and wrappers will be put
into 2.5.X. Then gradually changes to the tty and console layer. The good
news is that most platforms already support the new input api. Parsic,
ppc, and sh are using the input api. Where it is lacking is ix86, arm, and
mips. We have most the drivers needed for the ix86 platform. I'm working
on the ARM port. Over the weekend I nearly got ruby working on a iPAQ.
Their is a bug I have to find in the SA1100 fbdev driver but once I get
that going it will be smooth sailing. Well for mips, linux support really
sucks. I have a secondary branch for mips to get linux support going. I
plan to get ruby working on my sigmarion soon.

> I would like to know that, because if yes, I have to start removing a lot 
> of crap in the ruby CVS on the PPC side (like CONFIG_MAC_ADBKEYCODES) and 
> clean up a lot of the arch/ppc/kernel*_setup.c files (most of the 
> ppc_md.kbd* stuff is superfluous then).

Please do. PPC support is really lacking for ruby. The changes done so far
for ruby that affect platform dependent files (arch/xxx) are

1) The input api removes alot of obsolette stuff like aux_present flags
   etc.

2) Removal of conswitchp. Dummy con is no longer needed :-) 

3) Once I make vgacon firmware independent we can get ride of 
   struct screen_info. Yet to be done. It sort of works but the screen is
   a little funy, characters are moved over to the right to far. I will
   have to trace down the problem in the near future.

3) A new serial api is in the works. See the stuff in drivers/serial/ in
   ruby. Right now a massive cleanup is planned. I did some work on it
   yesterday trying to figure out how to create something similar to what
   fbdev has except for serial devices. It really is wasteful to go threw
   the tty layer for events from a input device. Plus do we really want to 
   be able to open a POSIX terminal on a joystick. Dumb dumb, just plain
   dumb.

> I'm a little bit undecided yet about CONFIG_MAC_EMUMOUSEBTN... Unless we 
> will have a event mixer device in 2.5, fixing it up in userspace is still 
> tricky. On the other side getting rid of CONFIG_MAC_EMUMOUSEBTN will make 
> mac_hid.c superfluous.

I seen a bunch of people posting they have some kind of a mixer. I was
hoping they all would put their heads together and merge all their code.
The fact is we do need this. Especially for support on the mips platform
to support IRIX /dev/shmiq (a shared input queue). The hard part is handling 
the absolute values.

Re: linux 2.5 vs. ruby

[James S. <jsi...@tr...>]

> > That is the plan. At first mostly new drivers and wrappers will be put
> > into 2.5.X. Then gradually changes to the tty and console layer. The good
> > news is that most platforms already support the new input api. Parsic,
> > ppc, and sh are using the input api. Where it is lacking is ix86, arm, and
> > mips. We have most the drivers needed for the ix86 platform. I'm working
> 
> And m68k and SPARC?

Their are a few drivers in drivers/input for keyboards on the m68k and
SPARC platform. The SPARC platform will require the serial driver (rz.c)
to be rewritten. 

For SPARC that works on ix86:

sunkbd.c: Sun keyboard driver

SPARC stuff that doesn't work, partially converted.

sun8042.c: Ultra/AX i8042 chipset support

Any other keybaord drivers.

For m68k we have the following working:

amijoy.c     :Driver for Amiga joysticks for Linux/m68k 
amikbd.c     :Amiga keyboard driver for Linux/m68k 
amimouse.c   :Amiga mouse driver for Linux/m68k
q40kbd.c     :Q40 PS/2 keyboard controller driver for Linux/m68k

What is needs to be converted on the m68k:

atarijoy.c   :Atari Joystick Driver
atarikbd.c   :Atari Keyboard driver 
atarimouse.c :Atari Mouse Driver

hphil.c	     :HP300 Human Interface Loop driver
apollokbd.c  :Apollo keyboard and mouse driver. Needs to broken apart.

The above non converted files haven't been done because of the lack of
hardware docs. I attempted to convert but lacked the knowledge and
hardware to test the new drivers on.



For PS/2 type keyboards that interface to serial ports we have
ps2serkbd.c. Has been tested for certain setups. 

Re: linux 2.5 vs. ruby

[Geert U. <ge...@li...>]

On Thu, 5 Jul 2001, James Simmons wrote:
> > what is the status of the ruby CVS (input layer part) vs. linux 2.5? Will 
> > we be integrated starting from 2.5.0?
> 
> That is the plan. At first mostly new drivers and wrappers will be put
> into 2.5.X. Then gradually changes to the tty and console layer. The good
> news is that most platforms already support the new input api. Parsic,
> ppc, and sh are using the input api. Where it is lacking is ix86, arm, and
> mips. We have most the drivers needed for the ix86 platform. I'm working

And m68k and SPARC?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

linux 2.5 vs. ruby

[Franz S. <Fra...@la...>]

Hi,

what is the status of the ruby CVS (input layer part) vs. linux 2.5? Will 
we be integrated starting from 2.5.0?

I would like to know that, because if yes, I have to start removing a lot 
of crap in the ruby CVS on the PPC side (like CONFIG_MAC_ADBKEYCODES) and 
clean up a lot of the arch/ppc/kernel*_setup.c files (most of the 
ppc_md.kbd* stuff is superfluous then).

I'm a little bit undecided yet about CONFIG_MAC_EMUMOUSEBTN... Unless we 
will have a event mixer device in 2.5, fixing it up in userspace is still 
tricky. On the other side getting rid of CONFIG_MAC_EMUMOUSEBTN will make 
mac_hid.c superfluous.

Franz.

Re: [linux-fbdev] scrolling rewrite

[Geert U. <ge...@li...>]

On Tue, 3 Jul 2001, James Simmons wrote:
> I'm going to be rewritting the scrolling code for fbcon. So I need to make
> sure I cover all the bases for what hardware features can be used when.
> Since the hardware is deverse please post some conditions. Thanks.

Hardware tricks:

  - panning (large virtual screen, scrolling + copy at bottom/top)
  - y-wrap (split-screen, used by amifb)

And then there's the question whether copying rectangles is faster than just
redrawing the affected area. On some hardware it is, on other it isn't.

Many years ago we also had `copcon', the Amiga Copper console, but that project
died. It was quite interesting though, since it allowed to split the screen on
every character line and reorder the lines without redrawing.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

scrolling rewrite

[James S. <jsi...@tr...>]

I'm going to be rewritting the scrolling code for fbcon. So I need to make
sure I cover all the bases for what hardware features can be used when.
Since the hardware is deverse please post some conditions. Thanks.

Handling beep

[James S. <jsi...@tr...>]

   A question on how to approach this problem. The input api has the
ablity to send EV_SND events to a input device. Now I like to impliment
this for the console system via kd_mksound. At present only the sun
keyboard supports injecting sound which is apart of the keyboard driver.
For the ix86 platform we have the PC speaker. Now the PC speaker is apart
of the region the i8042 chipset uses but has nothing to do with the PS/2
keyboard or mouse.
   The question is should the beeper be a seperate device and we have a
hook for it in the console system or do we make it apart of the keyboard
driver and use the keyboards hook?

Re: A modest proposal...

[James S. <jsi...@tr...>]

> > Yes but input.c you just increase it from what I could see.
> 
> No:
> 
> 	dev->number = find_first_zero_bit(input_devices, INPUT_DEVICES);

Sorry I was looking at the dev->number = input_number which is always
increased and decreased.

Re: A modest proposal...

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

On Fri, Jun 29, 2001 at 12:27:10PM -0700, James Simmons wrote:
> 
> > > There is a limit to 256 event devices. Now you
> > > say that is a good number but given 5 input devices it whould take 15
> > > times unplugging and plugging them back in before you run out of numbers.
> > > So I like to suggest that we keep track of the "free" numbers and grab the
> > > lowest one.
> > 
> > We do this, at least in evdev.
> 
> Yes but input.c you just increase it from what I could see.

No:

	dev->number = find_first_zero_bit(input_devices, INPUT_DEVICES);

-- 
Vojtech Pavlik
SuSE Labs

Japanese keyboard layout

[James S. <jsi...@tr...>]

Hi!

   Looking at my PS/2 Japanesse keyboard I need to figure out what keys
are what. From what I have seen of they have the same layout pretty much.
I believ some people have worked with these keyboards. I like to know what
key events should be generated by the following keys.

The key to the left of the space bar. The two keys to the right of the
space bar. Caps lock key? A key by the espace key. Thanks.

Re: init functions

[Petr V. <VAN...@vc...>]

On 29 Jun 01 at 14:05, Paul Mundt wrote:

> This shouldn't really be that big of a deal.. if we use a linked list
> that devices insert themselves into via register_framebuffer(), it wouldn't
> be much more difficult to move nodes around the list in the order of which
> they were passed. For example:

What you are talking about? If you want to use kernel init functions
(no #ifdef MODULE in drivers), devices are initialized in link order
and there is no way to change it. It is way too long to do anything
after register_framebuffer() is invoked.

> video=matrox: video=vga16:
> 
> We obviously want the matrox to be initialized _prior_ to the vga16.. the
> matrox gets inserted at the head of the list and the vga16 after it. The
> quickest way to do this would be to have two lists.. one list for prioritized
> cards, and the primary one where register_framebuffer() appends to.

> This might seem kind of hackish, but it should be able to be done fairly
> cleanly.. and it'd be a better solution then the current hacks, IMO.

I'm lost. Either you want to remove code completely from fbmem.c - and
in that case you have nothing to reorder, as you have no control on fbdev
initialization order (so current possibility of reordering is lost)
and you even do not know init function addresses (so again no reordering),
or you still want fbmem control ordering - in that case I do not understand
what you are trying to do. Maybe real patch which changes at least one
device to use your scheme would help me, but one you sent in original
message was at least incomplete, as it initialized matroxfb twice
if someone did 'video=matrox:' on kernel commandline, and it did not
reduce namespace pollution, as fbmem still needed that symbol. So?
                                                Thanks,
                                                        Petr Vandrovec
                                                        van...@vc...
                                                        

Re: init functions

[Paul M. <pm...@mv...>]

On Fri, Jun 29, 2001 at 10:33:40PM +0000, Petr Vandrovec wrote:
> And after applying your hack we either (a) call some initialization
> twice or (b) cannot reorder framebuffers. If you do not know
> what I'm talking about, try booting your kernel with
>=20
> video=3Dvga16: video=3Dmatrox:
>=20
> and then
>=20
> video=3Dmatrox: video=3Dvga16:
>=20
> and look at completely different behavior (of course if you have
> at least matrox alone in the box; you can replace matrox/vga16 with
> framebuffer drivers you use). As long as there is no
> global kernel service to reorder device scanning (such as my kernel
> has for PCI), it is unavoidable to have this hack. With SCSI you can
> say that your main disk is /dev/sdq, but with framebuffers it is
> really fatal if something wents wrong and you even do not see what
> went wrong because of console is now on some videocard without attached
> monitor, or on vfb...
>                                                =20
This shouldn't really be that big of a deal.. if we use a linked list
that devices insert themselves into via register_framebuffer(), it wouldn't
be much more difficult to move nodes around the list in the order of which
they were passed. For example:

video=3Dmatrox: video=3Dvga16:

We obviously want the matrox to be initialized _prior_ to the vga16.. the
matrox gets inserted at the head of the list and the vga16 after it. The
quickest way to do this would be to have two lists.. one list for prioritiz=
ed
cards, and the primary one where register_framebuffer() appends to.

If we had a matrox, a vga16, and a tdfx card and the matrox and tdfx wanted
to be initialized first, then the matrox would be removed from the primary
list and inserted as the head of the prioritized list, the tdfx would then =
be
appended to it, and so on and so on. Once we ran out of video=3D options, t=
he
remainder of the primary list could be appended to the prioritized list, or
the prioritized list inserted at the head of the primary list.

This might seem kind of hackish, but it should be able to be done fairly
cleanly.. and it'd be a better solution then the current hacks, IMO.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: init functions

[Petr V. <VAN...@vc...>]

On 29 Jun 01 at 13:17, Paul Mundt wrote:

> #ifdef MODULE
> module_init(myfb_init);
> #endif
> module_exit(myfb_exit);

...
 
>     for (i = 0; i < NUM_FB_DRIVERS; i++)
>         if (fb_drivers[i].init)
>             fb_drivers[i].init();
> 
> Now this is cute and all, but it's about as practical as using a bulldozer
> to hunt down small furry creatures.

And after applying your hack we either (a) call some initialization
twice or (b) cannot reorder framebuffers. If you do not know
what I'm talking about, try booting your kernel with

video=vga16: video=matrox:

and then

video=matrox: video=vga16:

and look at completely different behavior (of course if you have
at least matrox alone in the box; you can replace matrox/vga16 with
framebuffer drivers you use). As long as there is no
global kernel service to reorder device scanning (such as my kernel
has for PCI), it is unavoidable to have this hack. With SCSI you can
say that your main disk is /dev/sdq, but with framebuffers it is
really fatal if something wents wrong and you even do not see what
went wrong because of console is now on some videocard without attached
monitor, or on vfb...
                                        Best regards,
                                                Petr Vandrovec
                                                van...@vc...
                                                

init functions

[Paul M. <pm...@mv...>]

Hello,

As I'm sure people have already begun noticing.. for frame buffer drivers,
we typically have something like:

int __init myfb_init(void)
{
	...
}

static void __exit myfb_exit(void)
{
	...
}

#ifdef MODULE
module_init(myfb_init);
#endif
module_exit(myfb_exit);

This is absolutely and completely broken beyond belief. module_init() takes
care of inserting the init function into the .initcall.init section which
does the initialization at boot time or when the module is inserted.

In addition to this, we're making a function that should be private global,
and we're using a cheap hack to use another cheap hack. Which brings me to
my next point.. for this bit, I direct you to fbmem_init().. particularly:

	for (i =3D 0; i < NUM_FB_DRIVERS; i++)
		if (fb_drivers[i].init)
			fb_drivers[i].init();

Now this is cute and all, but it's about as practical as using a bulldozer
to hunt down small furry creatures.

I can see how the above method might've been necessary in 2.1 and most of
2.2, but it's certainly not needed anymore. The only time it would've been
practical is when drivers were using the whole init_module()/cleanup_module=
()
thing.. where init_module() was simply a wrapper that ran the init routine
from inside the driver.

If there are any drivers left that are still using this, they're broken and
out of date anyways, and should be fixed. Even 2.2 has supported the
module_init()/module_exit() calls for quite awhile now..

For now, I suggest something like:

--- linux.orig/drivers/video/fbmem.c    Fri Jun 29 12:47:03 2001
+++ linux/drivers/video/fbmem.c Fri Jun 29 13:12:08 2001
@@ -826,10 +826,6 @@
         */
        for (i =3D 0; i < num_pref_init_funcs; i++)
                pref_init_funcs[i]();
-
-       for (i =3D 0; i < NUM_FB_DRIVERS; i++)
-               if (fb_drivers[i].init)
-                       fb_drivers[i].init();
 }

to get around stepping into the init function twice, so we can finally
get rid of the #ifdef MODULE around the module_init(), and finally make
the init call static.

Ideally, I'd like to do away with the fb_drivers[] entirely and simply move
to a linked list where drivers insert themselves when they register with
register_framebuffer(). I plan to work on a patch for this on the weekend.

Comments?

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.