linuxconsole-dev

Re: bruby (20021205 & 20021221) devfs usb-ohci

[Svetoslav S. <ga...@st...>]

Quoting Aivils Stoss <Aiv...@un...>:

> 
> >> Hi Aivilis,
> >> i wanted to ask you some questions, altough i couldn't find time
> for
> >> testing.
> >
> >I think he probably heard you the first time. I've now had about 20
> copies
> >of this - why?
once again sorry,
for some reason sf.net is resending my first mail all the time
:(

> ruby 2.4.20 backport several versions is buggy. Svetljo has right.
with the small diff(attached) bruby20021221 is quite stable for me,

[root@svetljo src]# uptime
 10:28:43  up 1 day, 11:31,  7 users,  load average: 1.15, 1.18, 1.11
[root@svetljo src]#

dvd & divx viewing, several kernel compilations, iozone , bonnie++ and that all
while seti@home is running
:) 
 
> Now available
> http://startx.times.lv/bruby-2.4.20-20021226.diff.bz2
> 
> Status: "beta" , stable for me
> Very small testers count not ensure "stable" status for all.
> 
> Input drivers: MAR-2002 (2.5.2 ruby CVS)
> USB-HID: 25-SEP-2002 (Johan Deneux patch-2.4.19-ff3)
> VT-handler: 1-NOV-2002 (synced with ruby CVS)
> 
> /proc file system support added for VT-handler.
> user can change VT<->keyboard bundle via

is it intended to be so, somehow my second console doesn't report it's keyboard,
i mean /proc/bus/console/01/keyboard is empty

[root@svetljo src]# cat /proc/bus/console/00/keyboard
isa0060/serio0/input0
[root@svetljo src]# cat /proc/bus/console/01/keyboard

[root@svetljo src]# ls -l /proc/bus/console/0*
/proc/bus/console/00:
total 0
-rw-r--r--    1 root     root            0 Dec 27 10:31 keyboard

/proc/bus/console/01:
total 0
-rw-r--r--    1 root     root            0 Dec 27 10:31 keyboard
[root@svetljo src]# cat /proc/bus/input/devices
I: Bus=0003 Vendor=05fe Product=0011 Version=0000
N: Name="Cypress Sem. PS2/USB Browser Combo Mouse"
P: Phys=
D: Drivers=mouse1 event3
B: EV=6
B: KEY=1f0000 0 0 0 0 0 0 0 0
B: REL=103

I: Bus=0003 Vendor=046d Product=c303 Version=0700
N: Name="Logitech    USB Keyboard"
P: Phys=
D: Drivers=kbd event2
B: EV=120002
B: KEY=7f ffe7207a c14057ff ffbeffdf ffffffff ffffffff fffffffe
B: LED=1f

I: Bus=0011 Vendor=0002 Product=0002 Version=0100
N: Name="PS2++ Logitech Mouse"
P: Phys=isa0060/serio1/input0
D: Drivers=mouse0 event1
B: EV=6
B: KEY=70000 0 0 0 0 0 0 0 0
B: REL=3

I: Bus=0011 Vendor=0001 Product=0002 Version=ab02
N: Name="AT Set 2 keyboard"
P: Phys=isa0060/serio0/input0
D: Drivers=kbd event0
B: EV=120002
B: KEY=41f9 fff9df20 efdfffdf ffefffff ffffffff fffffffe
B: LED=7

Re: bruby (20021205 & 20021221) devfs usb-ohci

[Aivils S. <Aiv...@un...>]

>> Hi Aivilis,
>> i wanted to ask you some questions, altough i couldn't find time for
>> testing.
>
>I think he probably heard you the first time. I've now had about 20 copies
>of this - why?

ruby 2.4.20 backport several versions is buggy. Svetljo has right.

Now available
http://startx.times.lv/bruby-2.4.20-20021226.diff.bz2

Status: "beta" , stable for me
Very small testers count not ensure "stable" status for all.

Input drivers: MAR-2002 (2.5.2 ruby CVS)
USB-HID: 25-SEP-2002 (Johan Deneux patch-2.4.19-ff3)
VT-handler: 1-NOV-2002 (synced with ruby CVS)

/proc file system support added for VT-handler.
user can change VT<->keyboard bundle via
/proc/bus/console/XX

Aivils Stoss

Re: bruby (20021205 & 20021221) devfs usb-ohci

[Chris <ch...@st...>]

[Tue, 24 Dec 2002 09:48:26 +0100] Message from svetljo:

> Hi Aivilis,
> i wanted to ask you some questions, altough i couldn't find time for
> testing.

I think he probably heard you the first time. I've now had about 20 copies
of this - why?

Chris
-- 
=[ http://www.starforge.co.uk/ ]===[ Explorer2260 Lead Designer and Coder. ]
=[ Public key: ]===================[ http://www.starforge.co.uk/pubkey.txt ]
=[ You will obey the corporate masters. ]
--
If life is a stage, I want some better lighting.

bruby (20021205 & 20021221) devfs usb-ohc(.config)

[svetljo <sv...@ly...>]

---
Svetoslav Dimitrov Slavtschev

sv...@ly...
sve...@we...


_____________________________________________________________
Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year.
http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus

bruby (20021205 & 20021221) devfs usb-ohci

[svetljo <sv...@ly...>]

Hi Aivilis,
i wanted to ask you some questions, altough i couldn't find time for testing.

i had some problems by compilation,
so i wanted to ask you if you use devfs, and in case you do,
how did you manage to compile vc_console.c, and why you did the change on about line 527 :
from :
devfs_unregister ( devfs_find_handle ( .....
to
devfs_find_and_unregister ( ...

with this change i get warnings during compilation, and errors on final linking of vmlinuz, if i revert it everything seems ok,but i coudn't find time to boot the kernel
##########################       /home/root/src/2.4/linux-2.4.20bruby-21dec/arch/i386/lib/lib.a /home/root/src/2.4/linux-2.4.20bruby-21dec/lib/lib.a /home/root/src/2.4/linux-2.4.20bruby-21dec/arch/i386/lib/lib.a \
        --end-group \
        -o vmlinux
drivers/char/char.o: In function `vcs_make_devfs':
drivers/char/char.o(.text+0x12e57): undefined reference to `devfs_find_and_unregister'
drivers/char/char.o(.text+0x12e88): undefined reference to `devfs_find_and_unregister'
make: *** [vmlinux] Error 1
##########################

i couldn't compile usb-ohci, and i got some problems with usb_make_path in  usb-net & usb-serial

#################################
depmod: *** Unresolved symbols in /lib/modules/2.4.20-bruby-no_acpi/kernel/drivers/usb/serial/usbserial.o
depmod:         usb_make_path
depmod: *** Unresolved symbols in /lib/modules/2.4.20-bruby-no_acpi/kernel/drivers/usb/usbnet.o
depmod:         usb_make_path
#################################

and usb-ohci :
################################# 
gcc -D__KERNEL__ -I/home/root/src/2.4/linux-2.4.20bruby-21dec/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=athlon  -DMODULE  -nostdinc -iwithprefix include -DKBUILD_BASENAME=usb_ohci  -c -o usb-ohci.o usb-ohci.c
usb-ohci.c:181: parse error before '*' token
usb-ohci.c:182: warning: function declaration isn't a prototype
usb-ohci.c: In function `urb_rm_priv_locked':
usb-ohci.c:183: `urb' undeclared (first use in this function)
usb-ohci.c:183: (Each undeclared identifier is reported only once
usb-ohci.c:183: for each function it appears in.)
usb-ohci.c:199: warning: implicit declaration of function `usb_release_bandwidth'
usb-ohci.c: At top level:
usb-ohci.c:215: parse error before '*' token
usb-ohci.c:216: warning: function declaration isn't a prototype
usb-ohci.c: In function `urb_rm_priv':
usb-ohci.c:220: `urb' undeclared (first use in this function)
usb-ohci.c: At top level:
usb-ohci.c:461: parse error before "urb_t"
usb-ohci.c:462: warning: function declaration isn't a prototype
usb-ohci.c: In function `sohci_return_urb':
usb-ohci.c:463: `urb' undeclared (first use in this function)
usb-ohci.c:464: `urb_t' undeclared (first use in this function)
usb-ohci.c:464: `urbt' undeclared (first use in this function)
usb-ohci.c:483: `hc' undeclared (first use in this function)
usb-ohci.c: At top level:
usb-ohci.c:539: parse error before '*' token
usb-ohci.c:540: warning: function declaration isn't a prototype
usb-ohci.c: In function `sohci_submit_urb':
usb-ohci.c:544: `urb' undeclared (first use in this function)
usb-ohci.c:664: warning: implicit declaration of function `usb_check_bandwidth'
usb-ohci.c:672: warning: implicit declaration of function `usb_claim_bandwidth'
usb-ohci.c: At top level:
usb-ohci.c:723: parse error before '*' token
usb-ohci.c:724: warning: function declaration isn't a prototype
usb-ohci.c: In function `sohci_unlink_urb':
usb-ohci.c:728: `urb' undeclared (first use in this function)
usb-ohci.c: At top level:
usb-ohci.c:1298: parse error before "urb_t"
usb-ohci.c: In function `td_fill':
usb-ohci.c:1299: number of arguments doesn't match prototype
usb-ohci.h:434: prototype declaration
usb-ohci.c:1301: `urb' undeclared (first use in this function)
usb-ohci.c:1303: `index' undeclared (first use in this function)
usb-ohci.c:1313: `ohci' undeclared (first use in this function)
usb-ohci.c:1320: `data' undeclared (first use in this function)
usb-ohci.c:1321: `len' undeclared (first use in this function)
usb-ohci.c:1324: `info' undeclared (first use in this function)
usb-ohci.c: At top level:
usb-ohci.c:1347: parse error before '*' token
usb-ohci.c: In function `td_submit_urb':
usb-ohci.c:1348: number of arguments doesn't match prototype
usb-ohci.h:435: prototype declaration
usb-ohci.c:1349: `urb' undeclared (first use in this function)
usb-ohci.c: In function `dl_transfer_length':
usb-ohci.c:1460: `urb_t' undeclared (first use in this function)
usb-ohci.c:1460: `urb' undeclared (first use in this function)
usb-ohci.c: At top level:
usb-ohci.c:1501: parse error before '*' token
usb-ohci.c:1502: warning: function declaration isn't a prototype
usb-ohci.c: In function `dl_del_urb':
usb-ohci.c:1503: `urb' undeclared (first use in this function)
usb-ohci.c: In function `dl_del_list':
usb-ohci.c:1590: `urb_t' undeclared (first use in this function)
usb-ohci.c:1590: `urb' undeclared (first use in this function)
usb-ohci.c: In function `dl_done_list':
usb-ohci.c:1678: `urb_t' undeclared (first use in this function)
usb-ohci.c:1678: `urb' undeclared (first use in this function)
usb-ohci.c: In function `rh_int_timer_do':
usb-ohci.c:1854: `urb_t' undeclared (first use in this function)
usb-ohci.c:1854: `urb' undeclared (first use in this function)
usb-ohci.c:1854: parse error before ')' token
usb-ohci.c: At top level:
usb-ohci.c:1883: parse error before '*' token
usb-ohci.c: In function `rh_init_int_timer':
usb-ohci.c:1884: number of arguments doesn't match prototype
usb-ohci.h:439: prototype declaration
usb-ohci.c:1885: `urb' undeclared (first use in this function)
usb-ohci.c: At top level:
usb-ohci.c:1908: parse error before '*' token
usb-ohci.c: In function `rh_submit_urb':
usb-ohci.c:1909: number of arguments doesn't match prototype
usb-ohci.h:437: prototype declaration
usb-ohci.c:1910: `urb' undeclared (first use in this function)
usb-ohci.c: At top level:
usb-ohci.c:2114: parse error before '*' token
usb-ohci.c: In function `rh_unlink_urb':
usb-ohci.c:2115: number of arguments doesn't match prototype
usb-ohci.h:438: prototype declaration
usb-ohci.c:2116: `urb' undeclared (first use in this function)
make[2]: *** [usb-ohci.o] Error 1
###########################


regards,



svetljo

---
Svetoslav Dimitrov Slavtschev

sv...@ly...
sve...@we...



_____________________________________________________________
Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year.
http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus

Re: Detecting a keyboard

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

> > Will these per-keyboard keymaps go into 2.6, or is this a feature to
> > be implemented later?
> 
> Probably for later. Ask James, these are already beyond my realm of
> input core. ;)

It will have to wait until the next developement kernel to go in. The fact 
we managed to rework all the fbdev drivers to the ruby api and make the 
console system rely on the input subsystem is amazing. Unfortunely we have 
alot of drivers to work on. When the core console changes go in in the 
next developement cycle it will be easy as we will not have to mess with 
all the input and fbdev drivers next time around.

dell i8100 touchstick, 2.5 input -- further info

[James H. C. Jr. <cl...@jh...>]

[Ack.  Sent orig to wrong list....]

I've been researching the touchstick breakage in 2.5 on the i8100.

The board appears to use a SMC lpc47n252 superIO chip for keyboard and
ps/2 support.  Details on the chip are at:

http://www.smsc.com/main/datasheets/47n252.pdf
http://www.smsc.com/main/datasheets/47n252add.pdf

It has four ps/2 ports, matrix kb support and an i8051 compatible
µcore.  The i8051 code, then, is responsible for muxing the four ps/2
ports to the host's 0x60/0x64 ioports.

Dell's bios upgrade tool flashes the 47n252.  

I added some printk()s to i8042.c and confirmed that (unless something
else is accessing the kbc during the mux activation test) the synaptics,
et al mux protocol is not supported.  

Something the 2.5 input system is doing is resetting the kbc to a
state where it no longer muxes its ps2 ports.

Obviously, a dump of the i8051 or bios code would provide all the answers.

Does anyone have any ideas on where to go from here?

Having to use the touchpad is bloody irritating. :(

-JimC

Re: Bug report: 2.5.50 input + fbdev api

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

On Tue, Dec 10, 2002 at 02:47:30PM +0000, Alastair McKinstry wrote:

> Hi, 
> 
> A bug report against 2.5.50 + fbdev API, as posted to list:
> 
> Dell Dimension 4500, with USB keyboard (Sun type 5), ATI 128 card.
> With just a USB keyboard, no AT keyboard attached, I get unknown
> scancode errors from atkbd.c as keys are pressed.
> (USB compiled into kernel)
> 
> With both USB & AT keyboard, it freezes: keys don't work.
> 
> (Can debug further as required).

You need to load the USB HCI module, either usb-uhci or usb-ohci.

-- 
Vojtech Pavlik
SuSE Labs

Re: Detecting a keyboard

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

On Tue, Dec 10, 2002 at 06:59:37PM +0100, Arndt Schoenewald wrote:
> On Mon, Dec 09, 2002 at 11:30:39AM +0100, Vojtech Pavlik wrote:
> > 
> > > > We may need different keymaps on the different keyboards (indeed, this
> > > > might be essential ; one of the few reasons a normal user might have
> > > > multiple keyboards is to have different types)
> > > USB keyboards don't support variable mappings. 
> > 
> > It is planned to have per-keyboard keymaps (keycode->keysym), though no
> > scancode->keycode maps for USB.
> 
> Just curious: For what reasons do you plan to introduce per-keyboard
> keycode->keysym maps, but not scancode->keycode maps?

Scancode->keycode are already per-keyboard for AT keyboards and other
keyboards that need them. But for example on USB, there is no
scancode->keycode map, because all the information about the keyboard is
retrieved from the keyboard's USB descriptor.

> Is it because the keycode->keysym map is the more general case?

Basically yes.

The plan is to have every keyboard supply the same events to the input
subsystem. Then to map them using a keymap to what the user wants.

Basically, the scancode->keycode map should reflect the hardware layout of
the keyboard, and keycode->keysym the preferences of the user (language
layout, etc).

> Will these per-keyboard keymaps go into 2.6, or is this a feature to
> be implemented later?

Probably for later. Ask James, these are already beyond my realm of
input core. ;)

-- 
Vojtech Pavlik
SuSE Labs

Not sure

[<mi...@am...>]

Hi !..


Hi again

I am so sorry for not replying sooner it seems that, one of my emails seemed to have gone astray, so I thought I would reply hoping that you would still remember who I am :)) If by some chance you have changed your email, I guess I would have lost an opportunity too. shame :( 
Anyway, I'm still willing and waiting here http://www.singlers.com/index_vip.html If you want to contact me through the site again  you know where I am.

Kisses

Ali

Member Registration  http://www.singlers.com/index_vip.html







144l3 



3977yMwt7-896dwer0832cmiE4-630ZmkJ1483rtPR6-344pjlN1591Fl53

Re: 2.5 bk, input driver and dell i8100 nib+pad

[James H. C. Jr. <cl...@jh...>]

>>>>> "|" == David Woodhouse <dw...@in...> writes:

|> Weird. Does it come back to life if you suspend to RAM and resume?
|> Does the 'mouse' get detected as a Synaptics Touchpad by the
|> changed psmouse.c?

I've some more data on this.  I'd had been some time until I was able
to get a 2.5 to boot enough to run X....

Anyway, at 2.5.50 + a few csets, I had a spot where gpm could see the
nib iff /dev/mouse was symlinked to /dev/input/mice (c 13 63) but not
if it was linked to /dev/psaux (c 10 1) as it had been.

I hoped from that that X would also work, but I've not been able to
replicate that success even with gpm.  I don't know what magic insmod
made the difference (I wasn't trying to get it to work at the time,
just accidently hit the nib while at run level 3 and saw the gpm
cursor...).

As for a susend/resume cycle, this box has never been happy to do that.

-JimC

Synced to 2.5.51

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

Hi!

   I just synced up to 2.5.51. Give it a try.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: Detecting a keyboard

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

On Mon, Dec 09, 2002 at 11:30:39AM +0100, Vojtech Pavlik wrote:
> 
> > > We may need different keymaps on the different keyboards (indeed, this
> > > might be essential ; one of the few reasons a normal user might have
> > > multiple keyboards is to have different types)
> > USB keyboards don't support variable mappings. 
> 
> It is planned to have per-keyboard keymaps (keycode->keysym), though no
> scancode->keycode maps for USB.

Just curious: For what reasons do you plan to introduce per-keyboard
keycode->keysym maps, but not scancode->keycode maps? Is it because
the keycode->keysym map is the more general case?

Will these per-keyboard keymaps go into 2.6, or is this a feature to
be implemented later?

Thank you,
Arndt

Re: Bug report: 2.5.50 input + fbdev api

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

> A bug report against 2.5.50 + fbdev API, as posted to list:
>
> Dell Dimension 4500, with USB keyboard (Sun type 5), ATI 128 card.
> With just a USB keyboard, no AT keyboard attached, I get unknown
> scancode errors from atkbd.c as keys are pressed.
> (USB compiled into kernel)
>
> With both USB & AT keyboard, it freezes: keys don't work.
>
> (Can debug further as required).

Can you try out 2.5.51 now that it is out and includes my latest fbdev
work. Try it and if you have trouble could you post your .config file.

Bug report: 2.5.50 input + fbdev api

[Alastair M. <mck...@de...>]

Hi,=20

A bug report against 2.5.50 + fbdev API, as posted to list:

Dell Dimension 4500, with USB keyboard (Sun type 5), ATI 128 card.
With just a USB keyboard, no AT keyboard attached, I get unknown
scancode errors from atkbd.c as keys are pressed.
(USB compiled into kernel)

With both USB & AT keyboard, it freezes: keys don't work.

(Can debug further as required).



--=20
Alastair McKinstry <mck...@de...>
GPG Key fingerprint =3D 9E64 E714 8E08 81F9 F3DC  1020 FA8E 3790 9051 38F4

He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty he establishes a precedent that
will reach to himself.

- --Thomas Paine

Is that you?

[<mie...@cw...>]

Hi !..

think you replied to my personal ad!
Yes I do get a lot of responses but you got me curious I haven't done this
in a while so please forgive my nervousness. And I hope your still around,
(the good people always get taken fast) Anyway since I know a "little" about
you :) (that was cute by the way), you should take a look at me so that you
can decide if we match.
I'm not sure exactly what ad you replied to, I have a couple, but I do
have a detailed profile with a picture at http://www.hot.ee/vipsingles
Chris
Well...If you're not interested any more, that's ok too....
Have a great night.
Cya!....:)
ChrisBrenda27

Member Registration  http://www.hot.ee/vipsingles







0528fmjQ5-124lPFa9770yLpO4-789psUm3930CLLm9-209qpNK4353WjFm5-186iHPg865l67 



4025HAWH8-141DfmJ5195JZIV9-450RCvO7657YqIF5-501Cl45

Re: Detecting a keyboard

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

On Sat, Dec 07, 2002 at 08:26:59AM +0000, Alastair McKinstry wrote:
> Thanks.
> I'm working on the new debian-installer. I'm looking at the case of
> having  multiple potential keyboards in a computer, eg. USB & PS/2.
> I want to be able to tell, if possible, what keyboards are attached
> (possible in the USB case), and failing that (eg in the PS2 case)
> if there is a keyboard attached; so that if, eg we spot a keyboard on
> the USB port, we configure that, but is there also a keyboard on the
> PS/2 port ?

On 2.5, there is a complete list of attached input devices in
/proc/bus/input/devices. The list is correct only after you load all the
needed modules, of course, which shouldn't pose a problem.

On 2.4, the only way to check for a PS/2 keyboard is to grep 'dmesg' for 'AT
keyboard not present' ...

> We may need different keymaps on the different keyboards (indeed, this
> might be essential ; one of the few reasons a normal user might have
> multiple keyboards is to have different types)
> 
> Alastair
> 
> 
> On Sat, 2002-12-07 at 04:10, Brad Hards wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On Sat, 7 Dec 2002 06:20, Alastair McKinstry wrote:
> > > Hello,
> > >
> > > I am trying to detect, under Linux (2.4 or 2.5) if a keyboard is
> > > _present_ (attached to a PS/2 or other connector). (Similarly, same ges
> > > for any non-PC architecture. I know about USB, but PPC? Sparc?
> > > Acorn/Amiga/Atari?)
> > Easy on 2.5, you could just parse the /proc/bus/input/devices list. Or do an 
> > EVIOCGBIT to test for a partcular event interface.
> > 
> > What are you actually trying to accomplish?
> > 
> > Brad
> > 
> > - -- 
> > http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you?
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.0.6 (GNU/Linux)
> > Comment: For info see http://www.gnupg.org
> > 
> > iD8DBQE98XSfW6pHgIdAuOMRAqiMAJ4qw+Cn1FxmUfZWhEdLbszVHhicUQCcDMRy
> > uB37rMfI4+4XCp/iRLRFEhE=
> > =AuHg
> > -----END PGP SIGNATURE-----
> > 
> > 
> -- 
> Alastair McKinstry <mck...@de...>
> GPG Key fingerprint = 9E64 E714 8E08 81F9 F3DC  1020 FA8E 3790 9051 38F4
> 
> He that would make his own liberty secure must guard even his enemy from
> oppression; for if he violates this duty he establishes a precedent that
> will reach to himself.
> 
> - --Thomas Paine



-- 
Vojtech Pavlik
SuSE Labs

Re: Detecting a keyboard

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

On Sat, Dec 07, 2002 at 07:57:32PM +1100, Brad Hards wrote:

> On Sat, 7 Dec 2002 19:26, Alastair McKinstry wrote:
> > Thanks.
> > I'm working on the new debian-installer. I'm looking at the case of
> > having  multiple potential keyboards in a computer, eg. USB & PS/2.
> > I want to be able to tell, if possible, what keyboards are attached
> > (possible in the USB case), and failing that (eg in the PS2 case)
> > if there is a keyboard attached; so that if, eg we spot a keyboard on
> > the USB port, we configure that, but is there also a keyboard on the
> > PS/2 port ?
> You shouldn't care. They will always be mixed together.

Unless you use the event output, of course, or have a multihead
patched kernel.

> > We may need different keymaps on the different keyboards (indeed, this
> > might be essential ; one of the few reasons a normal user might have
> > multiple keyboards is to have different types)
> USB keyboards don't support variable mappings. 

It is planned to have per-keyboard keymaps (keycode->keysym), though no
scancode->keycode maps for USB.

-- 
Vojtech Pavlik
SuSE Labs

Re: Re[2]: [STATUS] fbdev api.

[Antonino D. <ad...@po...>]

On Sun, 2002-12-08 at 00:05, James Simmons wrote:
[...]
> Most of those fixes I already have in BK. I think yres_virtual being
> set to -1 is wrong. Also do we really need to call check var? The default
> mode is "trusted". Also fb_find_mode when we use it calls check_var.
> default_var already has the correct virtual res info. We do need to set
> fix tho :-)  Thanks for the fixes.
> 
That's okay James, the code that calls check_var() during init  is a
"temporary" code.  Rivafb happens to have a do_maximize() function that
computes for the highest yres_virtual when it's -1.  Currently, since
using fbset is broken, I do that to enable ypanning.  But it's not
important.

Tony

Re: Re[2]: [STATUS] fbdev api.

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

> diff -Naur linux-2.5.50-js/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
> --- linux-2.5.50-js/drivers/video/console/fbcon.c	2002-12-07 10:10:40.000000000 +0000
> +++ linux/drivers/video/console/fbcon.c	2002-12-07 10:12:11.000000000 +0000
> @@ -357,7 +357,7 @@
>  	area.dx = dx * vc->vc_font.width;
>  	area.dy = dy * vc->vc_font.height;
>  	area.height = height * vc->vc_font.height;
> -	area.width = width * vc->vc_font.height;
> +	area.width = width * vc->vc_font.width;
>
>  	info->fbops->fb_copyarea(info, &area);
>  }

Ug!!! A nasty typo. Thanks.

> @@ -1987,12 +1993,9 @@
>  		else
>  			update_screen(vc->vc_num);
>  		return 0;
> -	} else {
> -		/* Tell console.c that it has to restore the screen itself */
> -		return 1;
> -	}
> -	fb_blank(blank, info);
> -	return 0;
> +	}
> +	else
> +		return info->fbops->fb_blank(blank, info);
>  }

Hm. I have something similiar. That code needs to be cleaned up.

> Tony
>
> PS: James, can you also apply the following riva cleanup patch.  It
> fixes compile failures as well as removal of unused defines and
> declarations.

Most of those fixes I already have in BK. I think yres_virtual being
set to -1 is wrong. Also do we really need to call check var? The default
mode is "trusted". Also fb_find_mode when we use it calls check_var.
default_var already has the correct virtual res info. We do need to set
fix tho :-)  Thanks for the fixes.

@@ -1566,6 +1540,16 @@
                fb_find_mode(&info->var, info, mode_option,
                             NULL, 0, NULL, 8);
 #endif
+
+       info->var.yres_virtual = -1;
+       info->var.xres_virtual = info->var.xres;
+       if (rivafb_check_var(&info->var, info))
+               return 1;
+
+       info->fix.line_length = (info->var.xres_virtual * (info->var.bits_per_pi
+       info->fix.visual = (info->var.bits_per_pixel == 8) ?
+                               FB_VISUAL_PSEUDOCOLOR :
FB_VISUAL_DIRECTCOLOR;
+
        return 0;


MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re[4]: [STATUS] fbdev api.

[Tobias R. <ink...@un...>]

Hello Antonino,

Saturday, December 7, 2002, 11:22:07 AM, you wrote:

>> >> c) instruction:          | produces:
>> >>    ======================|==================
>> >>    1. typing abc def     | $ abc def
>> >>                          |          ^ (<- cursor)
>> >>    2. going three chars  | $ abc def
>> >>       ro the left        |       ^
>> >>    3. pressing backspace | $ abcddef
>> >>                          |      ^
>> >>    4. pressing enter     | -bash: abcdef: command not found
>> >>                          |

AD> Can you try this? It should fix the problem you mentioned as well as the
AD> emacs glitch.  Also, a quick fix for character map generation failures
AD> (KDFONTOP ioctl), ie when selecting console fonts.  Finally, if fbdev
AD> supports blanking, let's use that.
AD> [..patch..]
 
Ah, good job! Now working at the shell prompt is usable again. Many
thanks for your time exposure.

AD> Tony
-- 
cheers,
 Tobias

Re: Detecting a keyboard

[Brad H. <bh...@bi...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 7 Dec 2002 19:26, Alastair McKinstry wrote:
> Thanks.
> I'm working on the new debian-installer. I'm looking at the case of
> having  multiple potential keyboards in a computer, eg. USB & PS/2.
> I want to be able to tell, if possible, what keyboards are attached
> (possible in the USB case), and failing that (eg in the PS2 case)
> if there is a keyboard attached; so that if, eg we spot a keyboard on
> the USB port, we configure that, but is there also a keyboard on the
> PS/2 port ?
You shouldn't care. They will always be mixed together.

> We may need different keymaps on the different keyboards (indeed, this
> might be essential ; one of the few reasons a normal user might have
> multiple keyboards is to have different types)
USB keyboards don't support variable mappings. 

- -- 
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE98bf8W6pHgIdAuOMRAmeKAJwIVb5ssikwRD5Kicqbmi3vpXZLHgCfcGhb
Q5NTXhWCZ2LY5bZ7JGpUsm0=
=b9MT
-----END PGP SIGNATURE-----

Re: Detecting a keyboard

[Alastair M. <mck...@de...>]

Thanks.
I'm working on the new debian-installer. I'm looking at the case of
having  multiple potential keyboards in a computer, eg. USB & PS/2.
I want to be able to tell, if possible, what keyboards are attached
(possible in the USB case), and failing that (eg in the PS2 case)
if there is a keyboard attached; so that if, eg we spot a keyboard on
the USB port, we configure that, but is there also a keyboard on the
PS/2 port ?

We may need different keymaps on the different keyboards (indeed, this
might be essential ; one of the few reasons a normal user might have
multiple keyboards is to have different types)


Alastair


On Sat, 2002-12-07 at 04:10, Brad Hards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On Sat, 7 Dec 2002 06:20, Alastair McKinstry wrote:
> > Hello,
> >
> > I am trying to detect, under Linux (2.4 or 2.5) if a keyboard is
> > _present_ (attached to a PS/2 or other connector). (Similarly, same ges
> > for any non-PC architecture. I know about USB, but PPC? Sparc?
> > Acorn/Amiga/Atari?)
> Easy on 2.5, you could just parse the /proc/bus/input/devices list. Or do=
 an=20
> EVIOCGBIT to test for a partcular event interface.
>=20
> What are you actually trying to accomplish?
>=20
> Brad
>=20
> - --=20
> http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>=20
> iD8DBQE98XSfW6pHgIdAuOMRAqiMAJ4qw+Cn1FxmUfZWhEdLbszVHhicUQCcDMRy
> uB37rMfI4+4XCp/iRLRFEhE=3D
> =3DAuHg
> -----END PGP SIGNATURE-----
>=20
>=20
--=20
Alastair McKinstry <mck...@de...>
GPG Key fingerprint =3D 9E64 E714 8E08 81F9 F3DC  1020 FA8E 3790 9051 38F4

He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty he establishes a precedent that
will reach to himself.

- --Thomas Paine

Re: Re[2]: [STATUS] fbdev api.

[Antonino D. <ad...@po...>]

On Sat, 2002-12-07 at 03:59, Tobias Rittweiler wrote:
[...]
> >> c) instruction:          | produces:
> >>    ======================|==================
> >>    1. typing abc def     | $ abc def
> >>                          |          ^ (<- cursor)
> >>    2. going three chars  | $ abc def
> >>       ro the left        |       ^
> >>    3. pressing backspace | $ abcddef
> >>                          |      ^
> >>    4. pressing enter     | -bash: abcdef: command not found
> >>                          |
> 
> AD> I get this also. Seems to occur only with colored terms.  When I do 
> 
> AD> set TERM=vt100
> 
> AD> the problem disappears, so I thought this was an isolated case with my
> AD> setup :-). Similar glitches happen also in emacs with syntax
> AD> highlighting turned on.
> 
> Still there.
> 
Can you try this? It should fix the problem you mentioned as well as the
emacs glitch.  Also, a quick fix for character map generation failures
(KDFONTOP ioctl), ie when selecting console fonts.  Finally, if fbdev
supports blanking, let's use that.

diff -Naur linux-2.5.50-js/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.50-js/drivers/video/console/fbcon.c	2002-12-07 10:10:40.000000000 +0000
+++ linux/drivers/video/console/fbcon.c	2002-12-07 10:12:11.000000000 +0000
@@ -357,7 +357,7 @@
 	area.dx = dx * vc->vc_font.width;
 	area.dy = dy * vc->vc_font.height;
 	area.height = height * vc->vc_font.height;
-	area.width = width * vc->vc_font.height;
+	area.width = width * vc->vc_font.width;
 
 	info->fbops->fb_copyarea(info, &area);
 }
@@ -910,6 +910,12 @@
 
 	info->var.xoffset = info->var.yoffset = p->yscroll = 0;	/* reset wrap/pan */
 
+	/*
+	 * FIXME: need to set this in order for KDFONTOP ioctl
+	 *        to work 
+	 */
+	p->fontwidthmask = FONTWIDTHRANGE(1,16);
+
 	for (i = 0; i < MAX_NR_CONSOLES; i++)
 		if (i != con && fb_display[i].fb_info == info &&
 		    fb_display[i].conp && fb_display[i].fontdata)
@@ -1987,12 +1993,9 @@
 		else
 			update_screen(vc->vc_num);
 		return 0;
-	} else {
-		/* Tell console.c that it has to restore the screen itself */
-		return 1;
-	}
-	fb_blank(blank, info);
-	return 0;
+	} 
+	else 
+		return info->fbops->fb_blank(blank, info);
 }
 
 static void fbcon_free_font(struct display *p)

Tony

PS: James, can you also apply the following riva cleanup patch.  It
fixes compile failures as well as removal of unused defines and
declarations.

Thanks.

Re: Detecting a keyboard

[Brad H. <bh...@bi...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 7 Dec 2002 06:20, Alastair McKinstry wrote:
> Hello,
>
> I am trying to detect, under Linux (2.4 or 2.5) if a keyboard is
> _present_ (attached to a PS/2 or other connector). (Similarly, same ges
> for any non-PC architecture. I know about USB, but PPC? Sparc?
> Acorn/Amiga/Atari?)
Easy on 2.5, you could just parse the /proc/bus/input/devices list. Or do an 
EVIOCGBIT to test for a partcular event interface.

What are you actually trying to accomplish?

Brad

- -- 
http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE98XSfW6pHgIdAuOMRAqiMAJ4qw+Cn1FxmUfZWhEdLbszVHhicUQCcDMRy
uB37rMfI4+4XCp/iRLRFEhE=
=AuHg
-----END PGP SIGNATURE-----