linuxconsole-dev

Re: Compiling 2.4.0 with ruby.

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

> vt_ioctl.c:588: structure has no member named `vcs'

Try the lastest CVS. It is fixed. 

> I'm sure I don't understand what I'm doing and have some kernel config
> to do. 

You can send mne your .config file.

> Can I have a go on multiple consoles with cirrus logic (gd5480)
> hardware?

Not yet. This requires rewriting the fbcon layer which I'm about to do. 

> What are my limitations and what can I do? Am I limited to some certain
> hardware. 

Right now I have only worked with the vgacon and mdacon driver. I got both
working pretty well together.

> I have a hunch that multiple X sessions are a bit pre-mature
> at the moment, but that's what I'm after in the long run.

It can be done with XFree86. You have to do a 

start -vt 0
start -vt 16

This tells it which vc to run on. For the ruby tree 16 VCs belong to one
VT. Unfortunely I haven't got the fbcon layer going yet. Also for each
fbdev driver we have to make them firmware independent as well. Since most
video cards depend on the BIOS to intialize them. Unfortunely PC BIOS
don't see multiple video cards so only the first one on the PCI bus gets
intialized :-(

Re: splitting ruby

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

At 18:10 2001-01-10, James Simmons wrote:

> > Now 2.4.0 is out, whats next?
>
>A lot more work :-)
>
> > I think it might be a good idea to split ruby into 2 parts: the input side
> > (mostly working) and the console parts (still under dev), and try to get
> > the input side stuff into 2.4.1.
>
>I agree except you will not see the rest of the input stuff go into
>2.4.X. We will have to wait until 2.5.0. I have talked to Geert about this
>as well. I think the best attack plan is:
>
>1) Dump all the input drivers into the console system.
>2) Change all the fbdev drivers too.
>3) Change the console system.
>
>I don't know if linus would be willing to dump all our work in at one
>time. If he would be willing to do so then I would dump it all in. This of
>course would require that we have partily working functionality on ALL
>platforms. I can test the stuff on PPC, sparcs and alpha as well but
>haven't yet. Plus I need to get into contact with the other platform
>developers for this.

Well, I don't expect problems for PPC, as the adbhid.c driver is already 
part of 2.4.0, (sigh, reminds me to merge PPC code between ruby and 2.4.0) 
including the rest of the input code in 2.5.0 will just simplify the code 
and clarify configuration (especially on HW supporting both ADB and PS2 
keyboards) for us.

My TODO list for the full input code merge on PPC is quite short:
  - drop the emulate_raw() support for ADB keycodes, present in 2.4
  - drop the emulation code for 2nd and 3rd mouse button (maybe not?)
  - eventually write a handler kmmdev.c, that mixes keyboard and mouse 
events onto a single device (similar to /dev/input/mice) running the event 
protocol

Franz.

Re: splitting ruby

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

> Now 2.4.0 is out, whats next?

A lot more work :-)  

> I think it might be a good idea to split ruby into 2 parts: the input side
> (mostly working) and the console parts (still under dev), and try to get
> the input side stuff into 2.4.1.

I agree except you will not see the rest of the input stuff go into
2.4.X. We will have to wait until 2.5.0. I have talked to Geert about this
as well. I think the best attack plan is:

1) Dump all the input drivers into the console system. 
2) Change all the fbdev drivers too. 
3) Change the console system.

I don't know if linus would be willing to dump all our work in at one
time. If he would be willing to do so then I would dump it all in. This of
course would require that we have partily working functionality on ALL
platforms. I can test the stuff on PPC, sparcs and alpha as well but
haven't yet. Plus I need to get into contact with the other platform
developers for this.

Re: splitting ruby

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

At 14:51 2001-01-09, Justin Cormack wrote:
>Now 2.4.0 is out, whats next?
>
>I think it might be a good idea to split ruby into 2 parts: the input side
>(mostly working) and the console parts (still under dev), and try to get
>the input side stuff into 2.4.1.

I'd _love_ to see this happen as it finally unlinks char/keyboard.c from 
char/pc_keyb.c (which is a big win for non-x86 and embedded people), but I 
doubt a bit Linus will accept it for the 2.4 series...

Franz.

Compiling 2.4.0 with ruby.

[Adam H. <sv...@ea...>]

I get these errors when compiling 2=2E4=2E0 with ruby=2E

vt_ioctl=2Ec: In function `con_set_cmap':
vt_ioctl=2Ec:588: structure has no member named `vcs'
vt_ioctl=2Ec: In function `vt_ioctl':
vt_ioctl=2Ec:933: structure has no member named `vcs'
vt_ioctl=2Ec:945: structure has no member named `vcs'
vt_ioctl=2Ec:1071: structure has no member named `vcs'
vt_ioctl=2Ec:1097: structure has no member named `vcs'
vt_ioctl=2Ec:1143: structure has no member named `vcs'

I'm sure I don't understand what I'm doing and have some kernel config
to do=2E Can I have a go on multiple consoles with cirrus logic (gd5480)
hardware?
What are my limitations and what can I do? Am I limited to some certain
hardware=2E I have a hunch that multiple X sessions are a bit pre-mature
at the moment, but that's what I'm after in the long run=2E

Cheers,
--=20
Adam Huuva / Easter-eggs                 Sp=E9cialiste GNU/Linux
44-46 rue de l'Ouest  -  75014 Paris  -  France -  M=E9tro Gait=E9
Phone: +33 (0) 1 43 35 00 37    -   Fax: +33 (0) 1 41 35 00 76
mailto:sventon@easter-eggs=2Ecom  -   http://www=2Eeaster-eggs=2Ecom

splitting ruby

[Justin C. <jp...@do...>]

Now 2.4.0 is out, whats next?

I think it might be a good idea to split ruby into 2 parts: the input side
(mostly working) and the console parts (still under dev), and try to get
the input side stuff into 2.4.1.

Any thoughts?

justin

Recent News

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

Hi folks!!

    Sorry I have been away for awhile. First the holidays and second the
amount of code I have been working on. As you can see I have almost
finished the universal scrollback code. It still has a few problems that
I need to resolve but it is a important step to allow the removal of low
level driver hacks to support this feature (vgacon and fbcon). This means
we can soon begin work on rewriting the fbcon layer. I have synced are
tree with 2.4.0 :-) so give it a try. 

Re: questions about your project

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

Sorry about the delay. The holidays and all. As you can see this list is
very quite.

> 1.
> 
> I have written a kernel patch which allows a process which has
> a virtual console open in read mode to call an ioctl() on it to
> inject a small string of characters into the keyboard input as
> if they had been typed on the keyboard.  It only accepts the
> string if it won't overflow the buffer.  I personally have a
> few uses for this, and even though I have not fully studied it
> for security concerns and best practices, I've already put it
> into use on my systems.  It comes with a small C program which
> lets scripts inject data, including converting \ and ^ notation
> (in the sample program, not the ioctl).  Although a number of
> people have suggested I use pty's to do the things I needed this
> for, I consider a pty and the program that has to stay keeping
> the pty side open as being overhead I don't want, considering
> that I only inject data rather infrequently.
> 
> Is this an area which would be considered to be part of the
> virtual console redevelopment effort?

I like to look at this patch. Could you post it to the list?
 
> 2.
> 
> I've been interested in frame buffer consoles, but I have found
> that for many uses, they remain to slow.  Further, some of the
> ways they were is causing difficulty with how I use them.

This is because the graphical console are usually drawn pixel by pixel :-( 
I plan to have the drivers moved over to start using the accel engine
more.

> In particular, I find myself frustrated with the lack of distinct
> console abstraction with frame buffers.  There is technically
> just one frame buffer, with limited access.  

I couldn't agree with you more. In fact this is one of the reasons for
this project.

> What I really would
> like to see is frame buffering where each virtual console has its
> entire screen cached (and yes, I understand this can be as much
> as 4 megabyte or more per console) so that when switching consoles,
> the original contents are always re-presented, and the processes
> owning that console can make changes while I'm "away" and I can
> see the results of those changes when I switch back.

We don't cache the framebuffer due to memory size and complexity. We do
have a text buffer that is video card independent which stores the screen
image as if it was in text mode. This allows for what you are suggesting. 

> I'd also like to see one other feature, which could help address
> the space requirement for fully cached frame buffers, as well as
> the slowness issues I see.  This would be to have each virtual
> console individually define what mode they are in, be that frame
> buffer, or text mode.  That way I could choose to have 2 consoles
> in frame buffer mode with 4 megs each, and 50 consoles with no
> more than 16K each (based on my SVGATextMode extended size of
> 120x58).

Hum. Yes you can have different video modes for different consoles. I'm
in the process of making this driver independent. For the new console
system their are 16 consoles for every VT. SO you could have vgacon on
the first 16 and the second 16 you could have fbcon running.

> I've never found out if X Windows _must_, or simply _may_, use its
> frame buffer driver when Linux is booted up in frame buffer console
> mode, since I didn't stay with frame buffers long enough to try it.
> If it _must_, I'd sure like to see it changed to _may_ (with the
> obvious other choice of accessing the raw video device as it does
> without frame buffers).

Option "UseFBDev" 

By default XFree86 doesn't use the fbdev layer. You have to tell it to.

> 3.
> 
> Also, an idea I had a couple years ago, which I never followed up on
> with anyone, might be applicable here.  The idea was to have a screen
> saver device.  

/dev/vcsaX

> This device would work much like a virtual console
> (and in the case of frame buffers, should work like that, too).  But
> what it would be used for is to be the replacement content for when
> the screen saver timer pops.  It would initially have a blank content
> but a program could place content there to be seen in place of blank
> content when the timer pops.  There would also need to be a means for
> the program which has it open to know (without polling) when that
> screen is being displayed, and when it is not.  One thought is to
> call an ioctl() to enable signals USR1 and USR2 as indications.
> A program like Seti@Home could use that to start working only when
> its display is brought up by the screen saver.  Many other things
> could be possible.

You could do this rather easy in userland :-) You just have to turn off
the normal screen blanker in the kernel. Their is a simple ioctl call for
this. Set up your timer and poll for keyboard input. When no keyboard
input for X time then run blah program.

questions about your project

[<ph...@ip...>]

Hopefully this will go through w/o subscribing.  I am already
subscribed to way too many mailing lists as it is, and I don't
want to add another, unless this is something I am genuinely
interested in.  I couldn't exactly tell what the scope of the
project was from the web page (though certain things are clearly
covered, others not covered may be considered to be in scope but
just not an issue right now).

Please copy me directly on any replies.  Maybe the answers will
encourage my interest to join.

1.

I have written a kernel patch which allows a process which has
a virtual console open in read mode to call an ioctl() on it to
inject a small string of characters into the keyboard input as
if they had been typed on the keyboard.  It only accepts the
string if it won't overflow the buffer.  I personally have a
few uses for this, and even though I have not fully studied it
for security concerns and best practices, I've already put it
into use on my systems.  It comes with a small C program which
lets scripts inject data, including converting \ and ^ notation
(in the sample program, not the ioctl).  Although a number of
people have suggested I use pty's to do the things I needed this
for, I consider a pty and the program that has to stay keeping
the pty side open as being overhead I don't want, considering
that I only inject data rather infrequently.

Is this an area which would be considered to be part of the
virtual console redevelopment effort?


2.

I've been interested in frame buffer consoles, but I have found
that for many uses, they remain to slow.  Further, some of the
ways they were is causing difficulty with how I use them.

In particular, I find myself frustrated with the lack of distinct
console abstraction with frame buffers.  There is technically
just one frame buffer, with limited access.  What I really would
like to see is frame buffering where each virtual console has its
entire screen cached (and yes, I understand this can be as much
as 4 megabyte or more per console) so that when switching consoles,
the original contents are always re-presented, and the processes
owning that console can make changes while I'm "away" and I can
see the results of those changes when I switch back.

I'd also like to see one other feature, which could help address
the space requirement for fully cached frame buffers, as well as
the slowness issues I see.  This would be to have each virtual
console individually define what mode they are in, be that frame
buffer, or text mode.  That way I could choose to have 2 consoles
in frame buffer mode with 4 megs each, and 50 consoles with no
more than 16K each (based on my SVGATextMode extended size of
120x58).

I've never found out if X Windows _must_, or simply _may_, use its
frame buffer driver when Linux is booted up in frame buffer console
mode, since I didn't stay with frame buffers long enough to try it.
If it _must_, I'd sure like to see it changed to _may_ (with the
obvious other choice of accessing the raw video device as it does
without frame buffers).

Would this project be addressing issues like these?


3.

Also, an idea I had a couple years ago, which I never followed up on
with anyone, might be applicable here.  The idea was to have a screen
saver device.  This device would work much like a virtual console
(and in the case of frame buffers, should work like that, too).  But
what it would be used for is to be the replacement content for when
the screen saver timer pops.  It would initially have a blank content
but a program could place content there to be seen in place of blank
content when the timer pops.  There would also need to be a means for
the program which has it open to know (without polling) when that
screen is being displayed, and when it is not.  One thought is to
call an ioctl() to enable signals USR1 and USR2 as indications.
A program like Seti@Home could use that to start working only when
its display is brought up by the screen saver.  Many other things
could be possible.


Anyway, I'm just sort of checking to see if there is any mesh between
my interests, and what this project is working on.  I'd like to find
out more.

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phi...@ip... | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------

Re: mdacon

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

> the mdacon module doesn't detect my Hercules as a second adapter
> 
> 	mdacon: MDA card not detected.

Try Matan's suggestion.
 
> but stays in memory - bug or feature?

rmmod mdacon.o

If it fails to detect your card nothing is allocated and MOD_INC_COUNT
isn't called. rmmod will work to remove it.  

> My question: Does anybody else discovered this problem and/or a solution?

I haven't tried it as a module. Since you have a second card as vgacon do
you have a second keyboard. This way you can have two functional VTs. You
can use vgacon as your debugging console while testing mdacon. 

Re: mdacon

[Matan Ziv-Av <ma...@sv...>]

> the mdacon module doesn't detect my Hercules as a second adapter
> 
> 	mdacon: MDA card not detected.
> 
> but stays in memory - bug or feature?

Do you use a version from ruby's cvs?
Please try commenting out the two tests at line 217, and see if it then 
detects your card:

        /* Edward: These two mess `tests' mess up my cursor on bootup */

        /* cursor low register */
        if (! test_mda_b(0x66, 0x0f)) {
                return 0;
        }

        /* cursor low register */
        if (! test_mda_b(0x99, 0x0f)) {
                return 0;
        }




-- 
Matan Ziv-Av.                         ma...@sv...

mdacon

[Christian H. <ch...@ku...>]

Hi,

the mdacon module doesn't detect my Hercules as a second adapter

	mdacon: MDA card not detected.

but stays in memory - bug or feature?

My question: Does anybody else discovered this problem and/or a solution?
My first card is a ATI 3D Rage Pro AGP (rev 9).

Christian.

Re: building ruby

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

> I can't actually build ruby at the moment. I get errors in fbcon: eg

I haven't worked on the fbcon layer yet :-( I have been working on the
higher level stuff instead. In the hopes those changes will make fbcon
much leaner and cleaner. 

> also the Makefile in drivers/video is a bit broken (tries to link .c files).

Fixed. Dumb error :-( 

> Haven't had a chance to look at the code yet, will do later.

   Okay. Time to explain some things on what I plan to do and what
problems I have been having. 
   As you know when the console system was written it was based on vga
text modes since that was all linux supported at the time. Because of this
the console system was designed around the way the video memory was layed
out for VGA text mode. What I mean is the screen buffers that store
what is on each VC is in the same format as VGA text video mode. Every
other driver has to translate their data in video memory to vga text mode
data format and then place it in the screen buffer for the VC. For a extra
performance boost for the active VC the screen buffer points directly to
the VGA video memory region. 
    What I have been doing recently is added code such that each VC can
have its own font set and video resolution. Unfortunely I have been having
problems with the active screen buffer for vgacon. I have been dancing
around this issue since this requires alot of code rewrite for scrolling
in the higher level console code. Today I see I have to face this code
rewrite. Also with this code rewrite will use to get ride of that awful
scrollback hack for fbcon which has been causing alot of problems. That is
why I have been not working on the fbcon layer yet. So you will see
changes in the next few days for a new scrolling method. First I have
remove the vgacon memory = visible VC screenbuf hack. The independence of 
the screen buffer from the vga text mode lay out also will allow for much
greater flexiablity in supporting more things like 16 bit font glyphs.

   What is this new scrolling method? The idea I have is to a screen 
buffer laided out as follows:

------------
|          |
|          |
|----------|
| Visible  |   --->  translate --->       Video memory layout
|          |
|----------|
|          |
|          |
|----------|

We expand the screenbuf such that it is larger than the screen resolution
in rows by columns. 

    Scrolling is still a two part process. First we move the pointer that
describes the we the visiable screen is. Then we still have the hardware
hook in struct consw to pan the video mode. Then we draw the new data in
the screen buffer to video memory. The part that is tricky is when we
reach the bottom. Most people tell me they still want to be able to scroll
back, even when they VC switch away and come back. To still retain some
scroll back I have this idea:

|---------|      |---------| 
|         |      |*********|
|         |      |         |  <- Non visible moved as well to allow scroll   
|         |      |---------|     back  
|`````````|  --> | Visible |
|         |      |---------|
|---------|      |         |
| Visible |      |         |
|---------|      |---------|        


Any suggestions ?


BTW it is synced with test12. Vojtech joydev.c is broken. I have been
working on the video stuff so I haven't had time to fix it. Also sparc is
really really broken :-( Lots of work to do.

SourceForge: PROJECT DOWNTIME NOTICE

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

Due to hardware upgrade we will be down Friday December 15 from 9PM PST
(12 AM EST) until 3 AM PST. Nothing will be avaiable at this time. Thank
you.

building ruby

[Justin C. <jp...@do...>]

I can't actually build ruby at the moment. I get errors in fbcon: eg

gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test11-ruby/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i586    -c -o vesafb.o vesafb.c
In file included from vesafb.c:28:
fbcon.h:26: warning: `struct display' declared inside parameter list
fbcon.h:26: warning: its scope is only this definition or declaration,
fbcon.h:26: warning: which is probably not what you want.
fbcon.h:28: warning: `struct display' declared inside parameter list
fbcon.h:31: warning: `struct display' declared inside parameter list
fbcon.h:33: warning: `struct display' declared inside parameter list
fbcon.h:35: warning: `struct display' declared inside parameter list
fbcon.h:36: warning: `struct display' declared inside parameter list
fbcon.h:37: warning: `struct display' declared inside parameter list
fbcon.h:38: warning: `struct display' declared inside parameter list
fbcon.h:40: warning: `struct display' declared inside parameter list
vesafb.c: In function `vesafb_update_var':
vesafb.c:139: `fb_display' undeclared (first use in this function)
vesafb.c:139: (Each undeclared identifier is reported only once
vesafb.c:139: for each function it appears in.)
vesafb.c: In function `vesafb_get_var':
vesafb.c:168: `fb_display' undeclared (first use in this function)
vesafb.c: In function `vesafb_set_disp':


also the Makefile in drivers/video is a bit broken (tries to link .c files).

Haven't had a chance to look at the code yet, will do later.

Justin

Updates

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

Hi!

  More reports for more bug fixes. All the ioctl have pretty much been
tested and they passed. They all should be multihead safe. Next is to
enable console resizing for any console sub system. I will be attempting
this with vgacon. I even have early support for TIOCSWINSZ. This allows
for change the screen size of a single VC.

Status Report

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

Hi!

 I like to give the heads up on the latest developement. Things done this
week. I fixced several bugs for multiple VT support. I have a mda consoel
and vga console system running at the same time. You can do all the nice
features on each one. I also attempted the first port to a SUN workstation.  
Needless to say much work has to be done :-( So go have fun with the new
system. The next things to do:

Rewrite the scrolling code. This will seriously cleanup the fbcon layer.

Rewrite the console font code some more for per VC handling, unicode 16
support etc. 

Once these are done we can create a generic VC switching function. Then
most of the work is done. Of course their are other things yet to be done.

Have a pleasent weekend :-)

reboot notifier and i8042

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

Vojtech you place i8042_cleanup in machine_restart because notifier chains
are not called when panic is executed ?

Re: Keyboard questions

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

> There was an idea, that only Unicode keymaps are used and then the
> keyboard driver will translate to a user specified charset (through an
> ACM). Will this feature be in 2.4?

   From what I can remember the code for 2.4 and 2.2. are the same for
keymap handling. Understand if we went to unicode keymaps this would break
the currennt keyboard utility programs. Because of userland utilities I 
pretty much have kept the functionality the same. I have tried some
modifications which where needed.
   In the ruby tree the way it works is 8 bit characters coming in from a
tty or from the keyboard are translated by a ACM to a unicode value. Then
the unicode value is translated by a screen font map from unicode to which
glyph. Actually this is very similar to how 2.2. and 2.4. You could do the
same ACMs since ACM to unicode mappings don't have to be 1 to 1. I get
around this by using unicodes that are one to one. Often a character
has one unicode value to represent it and a combination of unicode
codes as well. 
 
> The compose mechanisams in kernel-2.2 didn't work for unicode. Can you
> tell me something more about the compose handling in 2.4? 
> 
> Will this work in 2.4:
> 	compose U+0435 grave to U+0450

I doubt it. More for me to work on ;-( 

> 
> And lastly, how good is UTF-8 support in the console in 2.4. There were
> some problems in kernel-2.2?

Still broken :-( I need to work on this more.

Re: [linux-fbdev] [Release] i810 frame buffer driver

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

> ... in 2.4. In 2.2. you can, it does not use spin_lock_irq to synchronize 
> console code.

That's right. I was thinking about a soultion to this for 2.5.X. I was
thinking about using a sempahore but I believe you can't use them in a
interrupt context since they use current. I was thinking about using 
atomic instead.

Re: patch for keybdev.c

[Katsura I. <ka...@to...>]

>Are you sure this change is correct? AFAIK 181 always mapped to 125, not 
>115 as in your table (this is in the linuxconsole CVS).
yes,it works fine.
you may be confusing "\" and "Yen",because "\" and "Yen" both generate same 
character "\".

HUT1_1 says
keyboard international
	 1 = \,_
	 2 = Hiragana_Katakana toggle
	 3 = Yen,|
	 4 = Henkan
	 5 = Muhenkan
and i found my japanese ps/2 keyboards generate scancodes
    \,_ => 115
    Hiragana_Katakana togle => 112
    Yen,| => 125
    Henkan => 121
    Muhenkan => 123

this map works fine with my usbkeyboards. and
"showkey -s" says  my ps/2 keyboards and usb keyboards generate same scancode.

you could see XFree86's keyboard definition to make sure

jp106 section of "/usr/X11R6/lib/X11/xkb/keycodes/xfree86" means
pc scancode ->	X's keycode(scancode+8) ->	Key
115		123				<AB11>	
112		120				<HKTG>
125		133				<AE13>
121		129				<XFER>
123		131				<NFER>

and "/usr/X11R6/lib/X11/xkb/sympols/jp" means
key <AB11> { [ backslash, underscore], [ kana_RO            ]       };
key <HKTG> { [ Hiragana_Katakana,Romaji     ]       };
key <AE13> { [ backslash, bar       ], [ prolongedsound     ]       };
key <XFER> { [ Henkan, Mode_switch  ]       };
key <NFER> { [ Muhenkan             ]       };


	     Katsura ITO (mailto:ka...@to...>

Keyboard questions

[Damjan <ar...@fr...>]

Hi,
I'm the maintainer of the macedonian keymaps for Linux and I have some 
questions about keymap handling in kernel-2.4. 

There was an idea, that only Unicode keymaps are used and then the
keyboard driver will translate to a user specified charset (through an
ACM). Will this feature be in 2.4?

The compose mechanisams in kernel-2.2 didn't work for unicode. Can you
tell me something more about the compose handling in 2.4? 

Will this work in 2.4:
	compose U+0435 grave to U+0450


And lastly, how good is UTF-8 support in the console in 2.4. There were
some problems in kernel-2.2?

Thanks.



-- 
Damjan Georgievski		|           Дамјан Георгиевски
Skopje, Macedonia		|           Скопје, Македонија

Re: patch for keybdev.c

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

At 04:56 28.11.00, Katsura ITO wrote:
>usb to pc keyboard emulation has incompatibility with japanese keyboard.
>see http://www.geocrawler.com/archives/3/2571/2000/7/0/3979255/
>and please append following patch.
>this problem is still in kernel-2.4.0-test11.
>
>      Katsura ITO
>
>--- linux/drivers/input/keybdev.c.original      Wed Nov 27 21:55:12 2000
>+++ linux/drivers/input/keybdev.c       Wed Nov 27 21:56:07 2000
>@@ -52,7 +52,7 @@
>         360, 93, 94, 95, 98,376,100,101,357,316,354,304,289,102,351,355,
>         103,104,105,275,281,272,306,106,274,107,288,364,358,363,362,361,
>         291,108,381,290,287,292,279,305,280, 99,112,257,258,113,270,114,
>-       118,117,125,374,379,259,260,261,262,263,264,265,266,267,268,269,
>+       118,117,125,374,379,115,112,125,121,123,264,265,266,267,268,269,
>         271,273,276,277,278,282,283,295,296,297,299,300,301,302,303,307,
>         308,310,313,314,315,317,318,319,320,321,322,323,324,325,326,330,
>         332,340,341,342,343,344,345,346,356,359,365,368,369,370,371,372 };

Are you sure this change is correct? AFAIK 181 always mapped to 125, not 
115 as in your table (this is in the linuxconsole CVS). In any case, read 
<http://www.usb.org/developers/data/devclass/hut1_1.pdf>, especially the 
description for keys 0x87-0x98, they relate 1:1 to the linux keycodes 
181-198 in linux/include/linux/input.h. And keep in mind that 
drivers/char/pc_keyb.c maps this keycodes again! Then again tell us how you 
would like to map the linux keycodes to AT keycodes. Or checkout the 
linuxconsole CVS (codename "ruby") from sourceforge and give us a diff for 
utils/scancodes.h.

BTW, it could even be that the reporting guy does run a setkey script for 
PS/2 keyboards, but not for USB keyboards...

Franz.

patch for keybdev.c

[Katsura I. <ka...@to...>]

usb to pc keyboard emulation has incompatibility with japanese keyboard.
see http://www.geocrawler.com/archives/3/2571/2000/7/0/3979255/
and please append following patch.
this problem is still in kernel-2.4.0-test11.

     Katsura ITO

--- linux/drivers/input/keybdev.c.original	Wed Nov 27 21:55:12 2000
+++ linux/drivers/input/keybdev.c	Wed Nov 27 21:56:07 2000
@@ -52,7 +52,7 @@
 	360, 93, 94, 95, 98,376,100,101,357,316,354,304,289,102,351,355,
 	103,104,105,275,281,272,306,106,274,107,288,364,358,363,362,361,
 	291,108,381,290,287,292,279,305,280, 99,112,257,258,113,270,114,
-	118,117,125,374,379,259,260,261,262,263,264,265,266,267,268,269,
+	118,117,125,374,379,115,112,125,121,123,264,265,266,267,268,269,
 	271,273,276,277,278,282,283,295,296,297,299,300,301,302,303,307,
 	308,310,313,314,315,317,318,319,320,321,322,323,324,325,326,330,
 	332,340,341,342,343,344,345,346,356,359,365,368,369,370,371,372 };

Re: [linuxsh-dev] touch-panel drivers

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

On Tue, Nov 07, 2000 at 06:23:01PM -0800, Jaswinder Singh wrote:
> Dear Vojtech and linuxconsole-dev group,
> 
> Can you please tell me, where i can find technical
> specs of Guze AHL-51S touchscreen.

I fear they're not available online. If you need a driver, look in the
linux-console CVS, and if you need a XFree driver, I have one, too, for
XFree 3.3.

-- 
Vojtech Pavlik
SuSE Labs