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