linuxconsole-dev

Re: TTY discipline for Joypad

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

> Hi there, 
> 
> I'm not sure this question is welcomed to this list.  I'm not the
> member of this list yet.

No problem. All questions are welcomed.

> Hence, I'm thinking using Joypad (with cursor key, analog joystick,
> four-buttons, two keys, and start button) to emulate keyboard.
> (There's a joypad driver already.)

Okay. Your doing something similar to the twiddler that we have in CVS
except you are working in the opposite direction. The twijoy driver makes 
a twiddler which is a handheld keyboard act as a joytsick. Of course
emulating a keyboard is much much harder. The input layer doesn't really
do key compose. I have a dreamcast here at work and I do have a keyboard
so I'm wondering how hard is it to get a dreamcast keyboard?

> I think I need to implement some special TTY discipline to input a
> character and to edit a line.  Is there any work done in this area?
> Please let me know.

Nope. We already have a TTY discipline interface to the input layer. Take
a look at the sunkbd.c driver. It is a keyboard that can plug into a
serial port, with a special adaptor. The only problem is with serial lines
devices you need a app called inputattach to actually use the serial
device. You need to do this after insmod the driver for it.  

Hope this helps. Thanks for your interest.

Re: Huge console switching lags

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

On Wed, Oct 03, 2001 at 09:58:30AM -0700, James Simmons wrote:
> > Well, there are indeed a few improvements to get with machine specific
> > optimisations on unaccelerated framebuffer.
> [snip]...
>=20
> Neat trick. Please note also that no read operations to the framebuffer
> are done by the fbcon layer. Such reads should be to the shadow buffers
> (vc_screenbuffer) instead. Reading the framebuffer is a userland operation
> and as such you really only tricks for reading in userland.=20
>=20
And while we're on the subject of architecture specific optimizations for
unaccelerated framebuffers (or framebuffers in general for that matter),
on SH4 you can remap the video memory area through a store queue and perform
all writes through the remapped store queue area (there are two store queue=
s,
each are 32bytes, and are flushed to the memory they were mapped to on a
prefetch instruction). This allows for very high speed writes to external
memory, as it was designed for.

Regards,

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

Re: Huge console switching lags

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

> Well, there are indeed a few improvements to get with machine specific
> optimisations on unaccelerated framebuffer.
[snip]...

Neat trick. Please note also that no read operations to the framebuffer
are done by the fbcon layer. Such reads should be to the shadow buffers
(vc_screenbuffer) instead. Reading the framebuffer is a userland operation
and as such you really only tricks for reading in userland. 

Re: [Linux-fbdev-devel] unified accerated interface

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

> > They can't be added to 2.2/2.4, because they need the pixel-based
> > functions, 2.2/2.4 accel is cell-based only.
> 
> Do you really have to implement the pixel-based functions for all possible
> values? E.g. for mfb, afb and ilbm it's quite complex, and the console driver
> doesn't really need it. That's why we have the support for width field for the
> cell-based operations.

    Well no. I like to think of the accel functions as being more
functionality oriented. When using the accel engine you are not thinking
draw these pixel. You are thinking fill in or copy this area. Their exist
hardware which is not pixel based so I hope the api is flexiable enough to
handle this. 
    The above examples you gave are such a example of not the usually
pixel. mfb easily fits into the cfb. The code I have written supports it. 
I thought about ilbm. Since it is a bunch of bitmaps (1 to N) being one
after another and each bitmap is a collect of a bit value at position X in
the pixel where X is bitmap N. We could easily write soft accel functions. 
For a rectfill it is a matter of taking a color to fill in with and
reading one bit at a time and filling in a are in the bitmap with a group
of 1's or a whole group of 0's. As you can see this could be really fast.
As for drawing a image that has to be units of 8 fbcon handles that by
ensuring only fonts of size of units of 8 are allowed to be used. It
still has the test to prevent something naugthy from happening. As for
userland doing stuff. The drawimage function really not avaliable for
userland. Sure we can have ioctl to test the draw functions for a driver 
but we should leave it at that. Only for debugging purposes.

Re: [Linux-fbdev-devel] unified accerated interface

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

> Well, if you use the latest Ruby they are available :-)
> 
> It's just a standard wrapper around mandatory functions, in fbmem.c
> If the #define exist in the header fb.h, they are there...
> 
> They can't be added to 2.2/2.4, because they need the pixel-based
> functions, 2.2/2.4 accel is cell-based only.

Actaully I have written a wrapper to be used with 2.4.X. I don't like
to think of it as pixel based but more functionality based. You can use
other things to preform something like a triangle fill. Say a texture map
of one color. 

Re: [Linux-fbdev-devel] unified accerated interface

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

> You can also extend fbtest to use the ioctl()s when they are available (how to
> find out?).

I added a api_version feild into fb_fix_screeninfo. For the current api
we have this as reserved[3] which means it should have a value of zero
(not implemented). For newer drivers they shoudl set that feild to one.

Re: TTY discipline for Joypad

[M. R. B. <mr...@0x...>]

* NIIBE Yutaka <gn...@m1...> on Wed, Oct 03, 2001:

> 
> I am the maintainer of SuperH port of Linux kernel.  Among targets,
> there's the Dreamcast, the video game console.  Linux works quite well
> on Dreamcast, however, most people doesn't have keyboard with
> Dreamcast, which is a problem.
> 

Keyboards and ps/2 adapters for the Dreamcast are a commodity and cheap.
What's the problem with requiring those who need keyboard access to the
Dreamcast to buy a keyboard?  I know you're going to argue that the ps/2
adapter isn't well supported, but it only takes a bit of testing to get
that correct.

> Hence, I'm thinking using Joypad (with cursor key, analog joystick,
> four-buttons, two keys, and start button) to emulate keyboard.
> (There's a joypad driver already.)
> 

What would be the use of this?  If anyone wanted to seriously login and use
their Dreamcast as a terminal, they would just go buy a keyboard, like many
have already done.  Using the joypad with it's 6 (max) magical buttons is
just plain silly.

M. R.

Re: [Linux-fbdev-devel] unified accerated interface

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

Geert Uytterhoeven wrote:

> Do you really have to implement the pixel-based functions for all possible
> values? E.g. for mfb, afb and ilbm it's quite complex, and the console driver
> doesn't really need it. That's why we have the support for width field for the
> cell-based operations.

None of those driver exist in Ruby ;-)

The idea is, the pixel-based functions are _required_ in Ruby. Either
the driver supply them, or there's some generic functions for
the most common pixel type.

The ioctls simply give access to these functions to userland apps. They
don't have to worry on specific hardware, they just say 'copy
area "width*height+sourceX+sourceY" to "destX,destY"', or
'fill area "w*h+x+y" with color C'.

If there's driver where pixel-based stuff is problematic, tell
James or Vojtech, as it might cause worse problems than userland
accelerated drawing...

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

Re: [Linux-fbdev-devel] unified accerated interface

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

On Wed, 3 Oct 2001, Romain Dolbeau wrote:
> Geert Uytterhoeven wrote:
> > You can also extend fbtest to use the ioctl()s when they are available (how to
> > find out?).
> 
> Well, if you use the latest Ruby they are available :-)
> 
> It's just a standard wrapper around mandatory functions, in fbmem.c
> If the #define exist in the header fb.h, they are there...
> 
> They can't be added to 2.2/2.4, because they need the pixel-based
> functions, 2.2/2.4 accel is cell-based only.

Do you really have to implement the pixel-based functions for all possible
values? E.g. for mfb, afb and ilbm it's quite complex, and the console driver
doesn't really need it. That's why we have the support for width field for the
cell-based operations.

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

Re: [Linux-fbdev-devel] unified accerated interface

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

Geert Uytterhoeven wrote:

> You can also extend fbtest to use the ioctl()s when they are available (how to
> find out?).

Well, if you use the latest Ruby they are available :-)

It's just a standard wrapper around mandatory functions, in fbmem.c
If the #define exist in the header fb.h, they are there...

They can't be added to 2.2/2.4, because they need the pixel-based
functions, 2.2/2.4 accel is cell-based only.

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

Re: [Linux-fbdev-devel] unified accerated interface

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

On Wed, 3 Oct 2001, Romain Dolbeau wrote:
> James Simmons wrote:
> > Nope. Only thing I have is fb_image. I moved the stuff together for
> > userland to use. I have ROP_X in the kernel section. Now it is useable to
> > userland. We could extend it to support image drawing as well. Draw
> > writers can see if they get the penguin when insmoding.
> 
> I've added a small 'acceltest' app in ruby/utils, it's supposed
> to move a coloured rectangle to the bottom right corner of the
> screen. Not tested...

You can also extend fbtest to use the ioctl()s when they are available (how to
find out?).

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

Re: Huge console switching lags

[Benjamin H. <be...@ke...>]

>>    The software accel functions needed by the console layer (copyarea,
>> fillrect, and drawimage) have been already written. Okay the drawimage one
>> needs alot of work. I haven't benchmarked the new code versus the current
>
>On x86 they'll probably make no difference at all, unless the old code
>is really really crap. Your bottleneck is the PCI bus. All you can do is
>avoid reads.

Well, there are indeed a few improvements to get with machine specific
optimisations on unaccelerated framebuffer.

One example is, on PPC, the use of a floating point register to do the
blits 64 bits at a time. This allow the PCI host controller to generate
bursts of 2 32 bits transactions (for machines with controllers unable
to write combine). Of course, having such optimisations in the kernel
is tricky because of the lazy FPU switching (well, at least on PPC),
but the point is that improvement _is_ possible.

Regards,
Ben.

Re: [Linux-fbdev-devel] unified accerated interface

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

James Simmons wrote:

> Nope. Only thing I have is fb_image. I moved the stuff together for
> userland to use. I have ROP_X in the kernel section. Now it is useable to
> userland. We could extend it to support image drawing as well. Draw
> writers can see if they get the penguin when insmoding.

I've added a small 'acceltest' app in ruby/utils, it's supposed
to move a coloured rectangle to the bottom right corner of the
screen. Not tested...

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

TTY discipline for Joypad

[NIIBE Y. <gn...@m1...>]

Hi there, 

I'm not sure this question is welcomed to this list.  I'm not the
member of this list yet.

I am the maintainer of SuperH port of Linux kernel.  Among targets,
there's the Dreamcast, the video game console.  Linux works quite well
on Dreamcast, however, most people doesn't have keyboard with
Dreamcast, which is a problem.

Hence, I'm thinking using Joypad (with cursor key, analog joystick,
four-buttons, two keys, and start button) to emulate keyboard.
(There's a joypad driver already.)

I think I need to implement some special TTY discipline to input a
character and to edit a line.  Is there any work done in this area?
Please let me know.

Thanks in advance, 
-- 

Use CVS from a few days ago.

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

Sorry folks but at present the CVS has issues. The first issue is I have
have new code to have each VT have it own struct tty_driver. Well I place
code that does work into CVS now but it breaks the fbcon layer. The goal
is to move the stuff in vt_console_init onto the driver side and shared
code into create_vt. At present I have had no luck. The second issue is
that the current CVS is behind the standard tree and the input drivers use
MODULE_LICENCE which is not avaliable in the 2.4.8. So you have to commit
it out for now. Once I fixed the above problem I will syn up to 2.4.10.
Thanks for your patience.

new developements.

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

Has you can see I have made time to work on this project again. I will be
shortly syncing up our stuff with the latest tree. First I need to make
each VT have its own struct tty_driver. Which I have pretty much have  
now. It needs to be more generic tho. I have a ugly hack in vt_console_init. 
Will be testing tonight and commiting.

Re: Huge console switching lags

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

> On x86 they'll probably make no difference at all, unless the old code
> is really really crap. Your bottleneck is the PCI bus. All you can do is
> avoid reads.

True. We have discussed the idea of placing the fonts into video memory
instead of system memory if the graphics card has room. At first I didn't
like the idea since handling scrolling would become more difficult. It can
be done tho with enough "tricks". I think it should be up to the driver
write where he/she can place the font image. This case drawimage becomes
copyarea except you grabbing off screen data. I have some thinking about
how to handle that.  

Re: Huge console switching lags

[Alan C. <al...@lx...>]

>    The software accel functions needed by the console layer (copyarea,
> fillrect, and drawimage) have been already written. Okay the drawimage one
> needs alot of work. I haven't benchmarked the new code versus the current

On x86 they'll probably make no difference at all, unless the old code
is really really crap. Your bottleneck is the PCI bus. All you can do is
avoid reads.

Alan

Re: Huge console switching lags

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

> > Well the reason the framebuffer suck is because the current api sucks for
> > them. It draws pixel by pixel. Slow slow slow!!! I have developed a new
> > api that takes advantage of the accel engine of graphics hardware. It is
> 
> Great. VESAfb doesnt have one. Lots of older machines dont have one.

   True. Of course VESAfb exist because we lack so fbdev drivers. In time
that problem should go away. Also many embedded devices, which I do for a
living, lack hardware acceleration. Well okay alot of modern PDA's are
staring to have accel engines. This doesn't mean you can't write really
good optimized software code for devices that lack hardware acceleration.
   The software accel functions needed by the console layer (copyarea,
fillrect, and drawimage) have been already written. Okay the drawimage one
needs alot of work. I haven't benchmarked the new code versus the current
code but you can see the difference. One of the big changes I have have
made is that on write data to the framebuffer word aligned and a long at
a time. For 8bpp you have 4 pixels written at a time. This makes for a
much tigher loop. On ix86 you can see a huge difference in performance due
to the word alignment. I knwo because at first I had a bug that wasn't
doing it right. After I fix that bug you could see the difference. 
    We use the same techniques at work for embedded devices where the cpus 
don't have the horse power like desktops. Every single line of code counts. 
I haven't ported the assembly versions for different platforms yet but I
plan to. I know from experience writing proper assembly on ARM or using
MMX will increase preformance many fold. 

Re: [Linux-fbdev-devel] unified accerated interface

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

> Commited. It uses a couple custom struct, I didn't see anything
> reasonably similar in fb.h ?

Nope. Only thing I have is fb_image. I moved the stuff together for
userland to use. I have ROP_X in the kernel section. Now it is useable to
userland. We could extend it to support image drawing as well. Draw
writers can see if they get the penguin when insmoding.

Re: [Linux-fbdev-devel] unified accerated interface

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

> I don't know about it being added into the linus tree but it would be
> really helpful for debugging. Add it anyways. I kind of provided the
> structs for it anyways.

Commited. It uses a couple custom struct, I didn't see anything
reasonably similar in fb.h ?

Note: it compiles, but hasn't been tested. Should work with any driver,
it's just 2 wrappers around fb_ops->fb_fillrect and fb_ops->fb_copyarea.

--=20
Romain DOLBEAU               | Ce que l'on con=E7oit bien s'=E9nonce
ENS Cachan / Ker Lann        | clairement, et les mots pour le dire
Thesard IRISA / CAPS         | arrivent ais=E9ment.
dol...@cl...    |       -- Nicolas Boileau

Re: [Linux-fbdev-devel] unified accerated interface

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

> My comments apply to the new "Ruby" framework, not to the current
> 2.2/2.4 stuff. Those use cell-based copy and erase (a cell contain one
> character), where Ruby use pixel-based copy and fill, much more
> flexible.
> 
> I've hacked a patch to add the two IOCTLS (for fillrect and copyarea),
> it's less than 90 lines. Maybe it's worth adding to Ruby ?

I don't know about it being added into the linus tree but it would be
really helpful for debugging. Add it anyways. I kind of provided the
structs for it anyways.

Re: New Input PS/2 driver

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

> Nice, I've just tested it and it works mostly, at least more than ruby. 
> Theres still problems with multiple keys. Holding shift and any of the 
> insert/delete/home/end/page up/page down keys, results in two warnings:
> unknown key(set 2, scancode 0x159 on input/0 ) pressed and released

Hm. Your keyboard generates a unquie scancode when pressing those key
combo that is lacking in the scancode to event table. I wonder what we
should label those scancodes. 
 
> Also when rebooting the input-kernel the BIOS reported keyboard error and I 
> had to do a full power-off.

I have this problem when I have 2 PS/2 keyboards plugged in. The input
driver doesn't depend on the firmware so it programs the i8042 chipset
itself. At reboot it in theory should reset itself to a sane state. This
is done by the i8042_controller_cleanup which is setup by 
register_reboot_notifier. This means it is not being called by the
notifier chain. Do you have this issue only when hitting alt-ctrl-delete?
 
> But I didnt see any off the autorepeat problems from ruby.

That is my fail. I changed some of the console code to use the input api
to reset the auto repeat rate. This is a bug in that code somewhere I have
to fix.

> This is becoming a pretty good alternative, if we can keep up a functional 
> patch against 2.4 until 2.5.

No problem. I hope to get it into Alan's tree soon.

Re: New Input PS/2 driver

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

> On Mon, Oct 01, 2001 at 09:47:53PM -0700, James Simmons wrote:
> > [... Announcement of his new PS/2 input driver ...]
> > http://www.transvirtual.com/~jsimmons/input-ps2.diff
> 
> Great! Does it, by chance, include the ability for bidirectional
> communication with a PS/2 device from a user space program?

Not yet. Their are ioctl calls  EVIOCSKEYCODE and EVIOCGKEYCODE but they
have never been implemented. It would be pretty easy to implement. I just
have to add something to input.c.

> I want to write a keymap download program for Handykey's Twiddler2
> (a chording keyboard connected to the PS/2 keyboard and mouse ports,
> see http://www.handykey.com), for which this would be very handy.

Take a look at input.h with the above ioctl values.

Re: [Linux-fbdev-devel] unified accerated interface

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

Chris Wright wrote:

> is there a standard way to access hardware acceleration without needing
> root privs or X? (sort of like accessing framebuffer before /dev/fb, you
> needed svgalib (root), or some X based library).

Romain Dolbeau answered:

> It could be done to add ioctl to allow app access to fb_fillrect and
> fb_copyarea, and maybe fb_imageblit. But I'm not sure it could make it to
> the Linux tree...

Oups, I forgot to check the header, and thought the original message was
on linux-console, not linux-fbdev.

My comments apply to the new "Ruby" framework, not to the current
2.2/2.4 stuff. Those use cell-based copy and erase (a cell contain one
character), where Ruby use pixel-based copy and fill, much more
flexible.

I've hacked a patch to add the two IOCTLS (for fillrect and copyarea),
it's less than 90 lines. Maybe it's worth adding to Ruby ?

-- 
DOLBEAU Romain               | The Gods made Heavy Metal
ENS Cachan / Ker Lann        |     and it's never gonna die
Thesard IRISA / CAPS         |           -- Manowar,
dol...@cl...    |    'The Gods made Heavy Metal'