linuxconsole-dev

Re: pm3 & CVS

[Romain D. <do...@ir...>]

Sven wrote:
> That said, i suppose the interresting part of the sourceforge project is the
> cvs server, as noting else seems to be active. Which cvs module should i get,
> and it is a whole linux kernel tree or only the console subsystem ?
> 
> mmm, it seems it is the whole kernel tree, and there is an AGAINST-2.4.7
>  diff available. Is the stuff i need to test in this patch ? i don't think so
> since it is 3 weeks old already.

the relevant module is 'ruby', which include a _partial_ kernel
tree. you need a regular 2.4.7 and move/copy the ruby files.
The AGAINST file is only a label to know the proper kernel
version, it's an empty file...

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: pm3 & CVS

[Sven <lu...@dp...>]

On Fri, Aug 24, 2001 at 10:03:28AM +0200, Romain Dolbeau wrote:
> Sven wrote:
> 
> > i would gladly try it, but as i don't seem to have the anterior mails, what
> > should i do, and where should i get the ruby tree from ?
> 
> <http://sourceforge.net/projects/linuxconsole/>
> 
> the rubyfied pm3fb is now integrated :-)
> 
> note: it compiles, but was never tested. HW accel
> is disabled (i.e. the functions are there but not
> used, pm3fb_ops still use cfb_*)
> 
> TIA for the test,

Ok, will test it as time permitts (possibly notuntil monday evening, but i
will try.)



That said, i suppose the interresting part of the sourceforge project is the
cvs server, as noting else seems to be active. Which cvs module should i get,
and it is a whole linux kernel tree or only the console subsystem ?


mmm, it seems it is the whole kernel tree, and there is an AGAINST-2.4.7
 diff available. Is the stuff i need to test in this patch ? i don't think so
since it is 3 weeks old already.

Friendly,

Sven Luther

Re: pm3 & CVS

[Romain D. <do...@ir...>]

Sven wrote:

> i would gladly try it, but as i don't seem to have the anterior mails, what
> should i do, and where should i get the ruby tree from ?

<http://sourceforge.net/projects/linuxconsole/>

the rubyfied pm3fb is now integrated :-)

note: it compiles, but was never tested. HW accel
is disabled (i.e. the functions are there but not
used, pm3fb_ops still use cfb_*)

TIA for the test,

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: pm3 & CVS

[Sven <lu...@dp...>]

On Wed, Aug 22, 2001 at 01:10:17PM +0200, Romain Dolbeau wrote:
> James Simmons wrote:
> 
> > Please do :-)
> 
> Done. untested as Ruby won't work on my PPC box.
> If a x86 user could try... (Sven ? :-)

Sorry for the delay, ...

i would gladly try it, but as i don't seem to have the anterior mails, what
should i do, and where should i get the ruby tree from ?

Friendly,

sven Luther

Re: pm3 & CVS

[Romain D. <do...@ir...>]

James Simmons wrote:

> Please do :-)

Done. untested as Ruby won't work on my PPC box.
If a x86 user could try... (Sven ? :-)

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: pm3 & CVS (was: Re: Ruby-fied off won't compile on Linux/PPC)

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

> OK. I have a preliminary (i.e. it compiles but is untested) pm3fb
> for ruby. the only change to mainstream ruby are in 
> 
> include/linux/fb.h (FB_ACCEL_3DLABS_PERMEDIA3 37)
> drivers/video/Makefile
> drivers/video/Config.in
> drivers/video/fbmem.c
> 
> May I commit the changes to those files ?

Please do :-)
k

pm3 & CVS (was: Re: Ruby-fied off won't compile on Linux/PPC)

[Romain D. <do...@ir...>]

James Simmons wrote:

> Done.

OK. I have a preliminary (i.e. it compiles but is untested) pm3fb
for ruby. the only change to mainstream ruby are in 

include/linux/fb.h (FB_ACCEL_3DLABS_PERMEDIA3 37)
drivers/video/Makefile
drivers/video/Config.in
drivers/video/fbmem.c

May I commit the changes to those files ?

TIA

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: Ug! Broken CVS.

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

On Thu, Aug 09, 2001 at 01:38:49PM -0700, James Simmons wrote:
> 
> > > I manged to get power.c to compile now but I get a nasty oops. I haven't
> > > managed to track it down but it appears to be somewhere in input_init.
> > 
> > Ouch. Seems like I did that when I added the hotplug stuff into the
> > input layer. It works on my machine, though (didn't test power.c).
> > I'll check if I can spot the error ...
> 
> I bet it is because I don't have hot plug enabled. More ifdefs are
> probable needed.

Added some.

-- 
Vojtech Pavlik
SuSE Labs

Re: Ug! Broken CVS.

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

> > I bet it is because I don't have hot plug enabled. More ifdefs are
> > probable needed.
> 
> I'll disable hotplug here and recompile.

Did it oops when you booted? power.c depends on CONFIG_PM being set. I
turned that off and it still oops. I will look into it tonight. 

Re: Ug! Broken CVS.

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

On Thu, Aug 09, 2001 at 01:38:49PM -0700, James Simmons wrote:
> 
> > > I manged to get power.c to compile now but I get a nasty oops. I haven't
> > > managed to track it down but it appears to be somewhere in input_init.
> > 
> > Ouch. Seems like I did that when I added the hotplug stuff into the
> > input layer. It works on my machine, though (didn't test power.c).
> > I'll check if I can spot the error ...
> 
> I bet it is because I don't have hot plug enabled. More ifdefs are
> probable needed.

I'll disable hotplug here and recompile.

-- 
Vojtech Pavlik
SuSE Labs

Re: Ug! Broken CVS.

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

> > I manged to get power.c to compile now but I get a nasty oops. I haven't
> > managed to track it down but it appears to be somewhere in input_init.
> 
> Ouch. Seems like I did that when I added the hotplug stuff into the
> input layer. It works on my machine, though (didn't test power.c).
> I'll check if I can spot the error ...

I bet it is because I don't have hot plug enabled. More ifdefs are
probable needed.

Re: Ug! Broken CVS.

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

On Tue, Aug 07, 2001 at 10:48:56PM -0700, James Simmons wrote:

> I manged to get power.c to compile now but I get a nasty oops. I haven't
> managed to track it down but it appears to be somewhere in input_init.

Ouch. Seems like I did that when I added the hotplug stuff into the
input layer. It works on my machine, though (didn't test power.c).
I'll check if I can spot the error ...

-- 
Vojtech Pavlik
SuSE Labs

Ug! Broken CVS.

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

I manged to get power.c to compile now but I get a nasty oops. I haven't
managed to track it down but it appears to be somewhere in input_init.

-----------------------------------------------------------------------------
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                 [ Alexander Viro on linux-kernel ]

Better printk

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

Hi folks!!

   Just to let you know printk has been reworked again. This time I
removed struct tty_driver from struct console. It was to heavy and I
realized both the console layer and the tty layer shared something inc
ommon, kdev_t. So it now uses the kdev_t feild instead. This now means 
register_console can handle setting up all the ahndling issues on its own
without the drivers help. This was a problem before and I had lots of fun
with serial console on the iPAQ because of this. Now it is fixed. The next
step is now to cleanup the register_tty_driver stuff. That needs to be
done be VT instead for all 64 VCs. 

Re: mousedev patch

[Charles D. <cd...@mv...>]

On Fri, Aug 03, 2001 at 12:10:55PM -0700, James Simmons wrote:
> > > Since this is such a issue and I also have written code to deal with =
this
> > > hot plug issue I will write a library to hides all the "nasty" from t=
he
> > > apps.
> >=20
> > I'm not sure if you can do that for apps that pass the fd from the
> > driver to the core to a central select() call which waits for events. If
> > they're braindamaged enough, they can't be helped.
>=20
> No doubt they have to reworked to use such a library but the benifeits
> outway the cost. If the api is simple and exist on many platforms you will
> see people migrate really fast.

I can see this API getting widespread use as soon as Ruby makes it in
to the official kernel (if it only provides an interface to the input
core) or sooner (if it additionally provides an interface to
/dev/psaux, /dev/ts [Compaq], /dev/touchpanel [Transmeta], /dev/tpanel
[VR41xx/Embedded Planet/HIOX] and all the other individual proprietary
interfaces out there). Of course, those interfaces won't last long (as
they'll hopefully all make it into the input core), but they'd be
great for encouraging early adoption.

Something providing all these capabilities would certainly make
reworking a few APIs quite worthwhile.

Re: mousedev patch

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

> > Method one is like the IRIX stuff:
> > 
> >    All input events are read from a input queue.
> >    Their is a special /dev/qctrlN so you can control each device.
> >    
> > Method two.
> >    We use one file to see if a new device is added/remove.
> >    Input events are read from individual devices. 
> > 
> > So it is really the flip side of a coin. Both methods get hairy.
> 
> I prefer method two. The point is that, though not being completely
> straightforward, every bit is kept simple and easy to understand.

Basically what we are doing is looking where to place the middleware. To
handle the one device file to many hardware devices we have to implement
some sort of filtering kernel side. The other side of the argument is we
push the filtering to userland. 

Charles is looking from the userland perspective to ensure backwards
compatiablity and making it easy to program. 

Vojtech and I are looking form the kernel side which involves adding
things like filters.



   After much discussion at work with my co worker we came up with the
pros and the cons of having it userland or kernel side. We looked at what
already exist. For linux we pretty much already have a system setup kernel
side. Its the network layer. We can do various types of network filtering. 
From the network layer we can see the issues that would come up. One is 
backwards compatiablity. If you upgrade your kernel you might have to
upgrade your software. Often we are left keeping the old code around just
to be backwards compatiable. Example is the ip toolchains. As you can see
in as time goes on the rules get more complex and more code gets added to
the kernel. 
    The other thing is userland has far better and faster evolving
tools when it comes to filtering than the kernel could ever have. Plus we
just can never know what kind of crazy filters people might want. What I
want to use my 3rd mouse only when the moon is full. This is something you
can't do easily kernel side. 
    The third thing about doing it userland side is if we implement a
library to hide such "nasties" is if the library API is go enough it can
be made to work on other platforms like BSD or solaris. This is the most
powerful thing since we can hide the very different types of behaviours
each system can exhibit and make them appear to work the same on each
system. Programs can be made to work on different platforms very easily. 

> > Since this is such a issue and I also have written code to deal with this
> > hot plug issue I will write a library to hides all the "nasty" from the
> > apps.
> 
> I'm not sure if you can do that for apps that pass the fd from the
> driver to the core to a central select() call which waits for events. If
> they're braindamaged enough, they can't be helped.

No doubt they have to reworked to use such a library but the benifeits
outway the cost. If the api is simple and exist on many platforms you will
see people migrate really fast.

Re: mousedev patch

[Charles D. <cd...@mv...>]

On Fri, Aug 03, 2001 at 10:37:53AM -0700, James Simmons wrote:
> Since this is such a issue and I also have written code to deal with this
> hot plug issue I will write a library to hides all the "nasty" from the
> apps.

As long as all communications from the library come through a single
pipe, that solution should work beautifully.

Re: mousedev patch

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

On Fri, Aug 03, 2001 at 11:04:35AM -0700, James Simmons wrote:
> 
> > > Would there be a problem with
> > > 
> > > 1) Opening and parsing /proc/input/devices.
> > > 1a) If no device is found either go to 1) if non-blocking is required
> > >     or select() on /proc/input/devices and then go to 1)
> > > 2) Opening the correct /dev/input/eventX
> > > 3) Read the event data
> > > 4) If -ENODEV received go to 1)
> > 
> > There are a few problems here:
> > 
> > 1. It isn't possible to read from two devices simultaneously while
> >    still conforming to the single-source requirement. This is
> >    extremely useful when, for instance, a device has both a touchpanel
> >    and USB ports (ie. the Hitachi webpad).
> 
> WHat do you mean by single source requirement?
> 
> > 2. Some mechanism will be required to allow the app to modify the fd
> >    in the select list used by the framework (in switching between
> >    steps 1 and 2 or 4).
> 
> Example? 
> 
> > > devices which generate lots of events and it'd be not a good idea in
> > > my opinion to feed all of them to the app.
> > 
> > So the app can use ioctl()s to decide what it does and doesn't wish to
> > hear. Perhaps the mixer initially provides nothing but attach and
> > detach events until the app adds additional sources via ioctl()s.
> 
> This is the mess a was talking about with the IRIX implementation. The
> more devices you have the more chance of losing event packets since you
> get a flood of them then. Plus what if one device goes crazy. Then 90%
> of the event packets coming in block the other devices. We actually had
> this problem with one device here at work. What had to do certain tricks
> to make sure everything got a fair share. The IRIX implement uses the
> qnctrl device files to manage this. 

I really would like to avoid this route if possible.

-- 
Vojtech Pavlik
SuSE Labs

Re: mousedev patch

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

On Fri, Aug 03, 2001 at 10:37:53AM -0700, James Simmons wrote:

> > Or do you have any alternate proposals?
> 
> Either way we end up with a mess.
> 
> Method one is like the IRIX stuff:
> 
>    All input events are read from a input queue.
>    Their is a special /dev/qctrlN so you can control each device.
>    
> Method two.
>    We use one file to see if a new device is added/remove.
>    Input events are read from individual devices. 
> 
> So it is really the flip side of a coin. Both methods get hairy.

I prefer method two. The point is that, though not being completely
straightforward, every bit is kept simple and easy to understand.

> > My basic requirement (which I'm loathe to negotiate on) is this:
> > 
> > - Hotplug and ready event notification must be available from one fd.
> > - It must not be necessary to perform any blocking calls (or a
> >   select() except with a zero timeout) on more than a single fd, this
> >   single fd presumably being that mentioned above.
> > 
> > Being able to wake the mouse driver from more than one source (ie.
> > separately for /proc/input/devices and /dev/input/eventX) will require
> > a level of app restructuring in more than one case which I believe is
> > unnecessary and will reduce driver availability without good cause.

Well, for one mouse you only need to select/read/whatever only one
file/device at a time. The file may change, though.

> Since this is such a issue and I also have written code to deal with this
> hot plug issue I will write a library to hides all the "nasty" from the
> apps.

I'm not sure if you can do that for apps that pass the fd from the
driver to the core to a central select() call which waits for events. If
they're braindamaged enough, they can't be helped.

-- 
Vojtech Pavlik
SuSE Labs

Re: mousedev patch

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

> > Would there be a problem with
> > 
> > 1) Opening and parsing /proc/input/devices.
> > 1a) If no device is found either go to 1) if non-blocking is required
> >     or select() on /proc/input/devices and then go to 1)
> > 2) Opening the correct /dev/input/eventX
> > 3) Read the event data
> > 4) If -ENODEV received go to 1)
> 
> There are a few problems here:
> 
> 1. It isn't possible to read from two devices simultaneously while
>    still conforming to the single-source requirement. This is
>    extremely useful when, for instance, a device has both a touchpanel
>    and USB ports (ie. the Hitachi webpad).

WHat do you mean by single source requirement?

> 2. Some mechanism will be required to allow the app to modify the fd
>    in the select list used by the framework (in switching between
>    steps 1 and 2 or 4).

Example? 

> > devices which generate lots of events and it'd be not a good idea in
> > my opinion to feed all of them to the app.
> 
> So the app can use ioctl()s to decide what it does and doesn't wish to
> hear. Perhaps the mixer initially provides nothing but attach and
> detach events until the app adds additional sources via ioctl()s.

This is the mess a was talking about with the IRIX implementation. The
more devices you have the more chance of losing event packets since you
get a flood of them then. Plus what if one device goes crazy. Then 90%
of the event packets coming in block the other devices. We actually had
this problem with one device here at work. What had to do certain tricks
to make sure everything got a fair share. The IRIX implement uses the
qnctrl device files to manage this. 

Re: Ruby-fied off won't compile on Linux/PPC

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

> It's "dolbeau", thanks a lot. No need for emergency, I'll be on vacation
> starting the 4 of august :-)

Done. Have a relaxing vaction. When you get back talk to Frank Sirl. He is
doing PPC work as well (more input side).

> BTW, neither a offb-only or offb+pm3fb [alpha ruby] or pm3fb-only
> 2.4.7-ruby will boot on my box, all drop me quickly to xmon. I still
> have the display on my main monitor [driven by the pm3] working in both
> case, so it's likely it crashes very early. According to my limited
> understanding of xmon and System.map, the crashes happen somewhere in
> register_console (at least the PC seems to point somewhere in
> register_console...)

Could you post a ksyoomps or Oops so I can try to track it.

Re: mousedev patch

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

> you asking what uses Compaq's /dev/ts? X, Microwindows and QtE (though
> it looks like it was patched in at the last minute there;
> additionally, X's /dev/ts support is rather broken, having no support
> for moving the cursor without the button depressed, though we should
> be fixing that here soon).

The /dev/ts stuff. I didn't expect it to be so broken.

> I absolutely agree that apps should be ported to use the event
> interface -- that's why I'm arguing for an event interface which is
> easy to port to (ie. doesn't require any framework changes, which
> listening on multiple fds does impose).

> Ahh -- I misread you. 'Twould work rather well for evdev, though,
> don't ya think?
> 
> Or do you have any alternate proposals?

Either way we end up with a mess.

Method one is like the IRIX stuff:

   All input events are read from a input queue.
   Their is a special /dev/qctrlN so you can control each device.
   
Method two.
   We use one file to see if a new device is added/remove.
   Input events are read from individual devices. 

So it is really the flip side of a coin. Both methods get hairy.

> My basic requirement (which I'm loathe to negotiate on) is this:
> 
> - Hotplug and ready event notification must be available from one fd.
> - It must not be necessary to perform any blocking calls (or a
>   select() except with a zero timeout) on more than a single fd, this
>   single fd presumably being that mentioned above.
> 
> Being able to wake the mouse driver from more than one source (ie.
> separately for /proc/input/devices and /dev/input/eventX) will require
> a level of app restructuring in more than one case which I believe is
> unnecessary and will reduce driver availability without good cause.

Since this is such a issue and I also have written code to deal with this
hot plug issue I will write a library to hides all the "nasty" from the
apps.

Re: Ruby-fied off won't compile on Linux/PPC

[<dol...@cl...>]

> Yes. Just send me your sourceforge account name. 

It's "dolbeau", thanks a lot. No need for emergency, I'll be on vacation
starting the 4 of august :-)

BTW, neither a offb-only or offb+pm3fb [alpha ruby] or pm3fb-only
2.4.7-ruby will boot on my box, all drop me quickly to xmon. I still
have the display on my main monitor [driven by the pm3] working in both
case, so it's likely it crashes very early. According to my limited
understanding of xmon and System.map, the crashes happen somewhere in
register_console (at least the PC seems to point somewhere in
register_console...)

Don't have the time to investigate the problem right now :-(

-- 
DOLBEAU Romain               | We'll know for the first time
ENS Cachan / Ker Lann        |     If we're evil or divine
Thesard IRISA / CAPS         |          -- Dio
dol...@cl...    |          in 'The Last In Line'

Re: imageblit, fb_image, weird size

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

> Another question: how are organized the data in fb_image->data,
> in particular for weird size and small depth ?
> 
> i.e. for a 6x11 font, each char is width == 6, height == 11,
> depth == 1. how are the 66 bytes put in data ? I assume
> byte-padded (i.e. 11 bytes for a char, with a two-bits-wide
> left column for padding), is it a valid assumption for _all_
> fb_image ?

Yes. Whatever the width of the image is it the last bits of data for each
row of data is byte padded. Even most accel engines require this. For
example the SUN 12x22 font whould have be formated as, where d represents 
data:

0123456789012345 

dddddddddddd0000
dddddddddddd0000
dddddddddddd0000
....
[22 times total]
dddddddddddd0000


BTW. The generic image drawing code doesn't suppor this. Also I haven't
restored the penguin drawing code. So if you don't see it don't think it
didn't boot.

Re: fb_info, fb_fix_screeninfo : questions

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

> 1) is it legit to extend fb_info ? i.e. using another
> struc xxfb_info w/ a fb_info field first, and using
> that in place of regular fb_info (like it's done
> in 2.4 and in the ruby atyfb)

  No. I haven't worked on the atyfb driver so the current structure will
change for that driver. For hardware specific stuff you want to create a
xxx_par structure. You have two advantages to this. One is it allows the
fbcon layer to only have to worry about struct fb_info. Otherwise we have
to do all kinds of casting in the upper console layer. Second is the
xxx_par structure could be used in other subsystems (DRI). That is why I
call the structs xxx_par instead of xxxfb_par.

So you want to make a xxx_par strucure. Fill it in with default values and
then do a info->par = par in xxxfb_init. When we go to set the video mode
via fb_set_var in check_var we do NOT change xxx_par. We only see if the
hardware can support the purposed state. It is in set_par where we set the
video mode.

> 2) where is filled fb_fix_screeninfo ? skeletonfb
> doesn't mention it. I believe it's in _set_par,
> but I'd like to be sure.

Yes it is. Only only want to change the fix field when a video mode
actually changes. Otherwise userland will get really confussed.

> 3) are the optional functions (_ioctl, _fill_rect...)
>  replaced by NULL or by the cfb_ or fb_ generic
> in the _ops struct ?

If the function is required then you must fill in that fb_ops field, even
if it uses the generic functions. If not required then it is safe to have
it has a NULL field. These functions are tested for NULL pointers.