Bug 90316 - [kbd] Keyboard "lock" key lights not working properly
Summary: [kbd] Keyboard "lock" key lights not working properly
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: sparc64 (show other bugs)
Version: 6.0-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Marius Strobl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-13 00:20 UTC by Matt D. Harris
Modified: 2007-09-30 20:44 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt D. Harris 2005-12-13 00:20:02 UTC
Keyboard driver info from dmesg...
puc1: <Zilog Z8530 dual channel SCC> mem 0x1000000-0x1000003 irq 2024 on sbus0
uart2: <z8530, channel A> on puc1
uart2: keyboard (1200,n,8,1)
kbd0 at sunkbd0
uart3: <z8530, channel B> on puc1

This is a standard Sun type5 keyboard and mouse combination. 

The situation is that the Cap lock, Compose, and Scroll lock lights are
always illuminated while FreeBSD is running.  The Num lock light never
becomes illuminated.  Though the toggles for each of these works
appropriately, that is, I can actually *use* the num/caps/scroll lock
features normally via the keyboard toggle keys, the light illumination
is never changed.  Compose, caps, and scroll lock lights are always on,
and num lock light is always off, regardless of those toggles. 

The problem is purely aesthetic in nature, but it'd be nice to have a fix.

Fix: 

Sorry, I'm willing to help any way that I can with testing code and such,
but I lack the expertise to work on this code myself. 
__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
How-To-Repeat: This is always the case on this system.  Other mentions of this exact same
behavior have appeared on the sparc64 mailing list, but no resolution was
ever reached, and it doesn't look like anyone has sent a pr about it either.
Comment 1 ru freebsd_committer freebsd_triage 2006-10-25 21:22:46 UTC
Responsible Changed
From-To: freebsd-sparc64->marius

Marius says he has a fix for this in the works.
Comment 2 dfilter service freebsd_committer freebsd_triage 2006-11-02 00:01:31 UTC
marius      2006-11-02 00:01:15 UTC

  FreeBSD src repository

  Modified files:
    sys/conf             files.sparc64 options.sparc64 
    sys/dev/uart         uart_kbd_sun.c uart_kbd_sun.h 
    sys/sparc64/conf     NOTES 
  Log:
  - In sunkbd_probe_keyboard() don't bother to determine the keyboard layout
    as we have no use for that info. Instead let this function return the
    keyboard ID and verify at its invocation in sunkbd_configure() that we're
    talking to a Sun type 4/5/6 keyboard, i.e. a keyboard supported by this
    driver.
  - Add an option SUNKBD_EMULATE_ATKBD whose code is based on the respective
    code in ukbd(4) and like UKBD_EMULATE_ATSCANCODE causes this driver to
    emit AT keyboard/KB_101 compatible scan codes in K_RAW mode as assumed by
    kbdmux(4). Unlike UKBD_EMULATE_ATSCANCODE, SUNKBD_EMULATE_ATKBD also
    triggers the use of AT keyboard maps and thus allows to use the map files
    in share/syscons/keymaps with this driver at the cost of an additional
    translation (in ukbd(4) this just is the way of operation).
  - Implement an option SUNKBD_DFLT_KEYMAP, which like the equivalent options
    of the other keyboard drivers allows to specify the default in-kernel
    keyboard map. For obvious reasons this made to only work when also using
    SUNKBD_EMULATE_ATKBD.
  - Implement sunkbd_check(), sunkbd_check_char() and sunkbd_clear_state(),
    which are also required for interoperability with kbdmux(4).
  - Implement K_CODE mode and FreeBSD keypad compose.
  - As a minor hack define KBD_DFLT_KEYMAP also in the !SUNKBD_EMULATE_ATKBD
    case so we can obtain fkey_tab from <dev/kbd/kbdtables.h> rather than
    having to duplicate it and #ifdef some more code.
  - Don't use the TX-buffer for writing the two command bytes for setting the
    keyboard LEDs as this consequently requires a hardware FIFO that is at
    least two bytes in depth, which the NMOS-variant of the Zilog SCCs doesn't
    have. Thus use an inlined version of uart_putc() to consecutively write
    the command bytes (a cleaner approach would be to do this via the soft
    interrupt handler but that variant wouldn't work while in ddb(4)). [1]
  - Fix some minor style(9) bugs.
  
  PR:             90316 [1]
  Reviewed by:    marcel [1]
  
  Revision  Changes    Path
  1.83      +5 -0      src/sys/conf/files.sparc64
  1.14      +2 -0      src/sys/conf/options.sparc64
  1.10      +379 -85   src/sys/dev/uart/uart_kbd_sun.c
  1.3       +3 -0      src/sys/dev/uart/uart_kbd_sun.h
  1.30      +10 -0     src/sys/sparc64/conf/NOTES
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 3 dfilter service freebsd_committer freebsd_triage 2007-09-30 20:33:25 UTC
marius      2007-09-30 19:33:19 UTC

  FreeBSD src repository

  Modified files:        (Branch: RELENG_6)
    sys/conf             files.sparc64 options.sparc64 
    sys/dev/uart         uart_kbd_sun.c uart_kbd_sun.h 
    sys/sparc64/conf     NOTES 
  Log:
  MFC: sys/conf/files.sparc64 1.83; sys/conf/options.sparc64 1.24;
       sys/dev/uart/uart_kbd_sun.c 1.10, 1.11 (partial), 1.13;
       sys/dev/uart/uart_kbd_sun.h 1.3; sys/sparc64/conf/NOTES 1.30
  
  - In sunkbd_probe_keyboard() don't bother to determine the keyboard layout
    as we have no use for that info. Instead let this function return the
    keyboard ID and verify at its invocation in sunkbd_configure() that we're
    talking to a Sun type 4/5/6 keyboard, i.e. a keyboard supported by this
    driver.
  - Add an option SUNKBD_EMULATE_ATKBD whose code is based on the respective
    code in ukbd(4) and like UKBD_EMULATE_ATSCANCODE causes this driver to
    emit AT keyboard/KB_101 compatible scan codes in K_RAW mode as assumed by
    kbdmux(4). Unlike UKBD_EMULATE_ATSCANCODE, SUNKBD_EMULATE_ATKBD also
    triggers the use of AT keyboard maps and thus allows to use the map files
    in share/syscons/keymaps with this driver at the cost of an additional
    translation (in ukbd(4) this just is the way of operation).
  - Implement an option SUNKBD_DFLT_KEYMAP, which like the equivalent options
    of the other keyboard drivers allows to specify the default in-kernel
    keyboard map. For obvious reasons this made to only work when also using
    SUNKBD_EMULATE_ATKBD.
  - Implement sunkbd_check(), sunkbd_check_char() and sunkbd_clear_state(),
    which are also required for interoperability with kbdmux(4).
  - Implement K_CODE mode and FreeBSD keypad compose.
  - As a minor hack define KBD_DFLT_KEYMAP also in the !SUNKBD_EMULATE_ATKBD
    case so we can obtain fkey_tab from <dev/kbd/kbdtables.h> rather than
    having to duplicate it and #ifdef some more code.
  - Don't use the TX-buffer for writing the two command bytes for setting the
    keyboard LEDs as this consequently requires a hardware FIFO that is at
    least two bytes in depth, which the NMOS-variant of the Zilog SCCs doesn't
    have. Thus use an inlined version of uart_putc() to consecutively write
    the command bytes (a cleaner approach would be to do this via the soft
    interrupt handler but that variant wouldn't work while in ddb(4)). [1]
  - Fix some minor style(9) bugs.
  
  PR:             90316 [1]
  
  Revision  Changes    Path
  1.73.2.4  +5 -0      src/sys/conf/files.sparc64
  1.13.2.1  +2 -0      src/sys/conf/options.sparc64
  1.5.2.4   +382 -86   src/sys/dev/uart/uart_kbd_sun.c
  1.2.2.1   +3 -0      src/sys/dev/uart/uart_kbd_sun.h
  1.19.2.3  +10 -0     src/sys/sparc64/conf/NOTES
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 4 Marius Strobl freebsd_committer freebsd_triage 2007-09-30 20:40:32 UTC
State Changed
From-To: open->closed


Close now that the fix finally has been backported to RELENG_6.