Re: Diff to support so-called gaming USB keyboards
On Tue, Jul 03, 2012 at 03:23:16PM -0700, Mike Larkin wrote:
Many low-cost USB keyboards have a limit of either 3 or 6 simultaneous
keypresses before they wedge and stop supplying any more keypress events
(at least until you release one of the pressed keys).
Some newer (usually called gaming) keyboards use a different way of
reporting keypress events in order to support an arbitrary number of
simultaneous keypresses (likely under the assumption that in certain
games, you might need more than 3 or 6 keys pressed at the same time).
Our USB HID keyboard code had some bad assumptions in it - namely, that
every key reported in this fashion was a 'modifier' key like shift,
alt, or control, and that there would only be 8 such keys maximum.
The diff below reworks the HID keyboard code a bit to remove these
assumptions and support these newer style USB keyboards. It also
changes the term 'modifier' to 'variable' which is a more proper
description of these keys (as per the HID spec), in various
comments and printfs.
If you have a USB keyboard (whether or not it is a gaming variety),
please test this diff to ensure that it does not break you. I've tested
on i386 and amd64 on a variety of keyboards and haven't seen any
problems, so it's time to turn it loose to a wider audience.
-ml
This keyboard is still working fine:
uhidev2 at uhub2 port 1 configuration 1 interface 0 Microsoft Natural\M-.
Ergonomic Keyboard 4000 rev 2.00/1.73 addr 2
uhidev2: iclass 3/1
ukbd1 at uhidev2: 8 variable keys, 6 key codes
wskbd2 at ukbd1 mux 1
wskbd2: connecting to wsdisplay0
uhidev3 at uhub2 port 1 configuration 1 interface 1 Microsoft Natural\M-.
Ergonomic Keyboard 4000 rev 2.00/1.73 addr 2
uhidev3: iclass 3/0, 1 report id
uhid0 at uhidev3 reportid 1: input=7, output=0, feature=0
Although it's still suffering from the fact I need to detach/attach the cables
upon every boot/suspend otherwise it just sits there playing dead. But that's
unrelated to this diff.
Index: hidkbd.c
===
RCS file: /cvs/src/sys/dev/usb/hidkbd.c,v
retrieving revision 1.5
diff -a -u -r1.5 hidkbd.c
--- hidkbd.c 9 Nov 2011 14:22:38 - 1.5
+++ hidkbd.c 29 Jun 2012 06:45:59 -
@@ -41,6 +41,7 @@
#include sys/kernel.h
#include sys/device.h
#include sys/ioctl.h
+#include sys/malloc.h
#include dev/usb/usb.h
#include dev/usb/usbhid.h
@@ -164,6 +165,8 @@
{
const char *parserr;
+ kbd-sc_var = NULL;
+
parserr = hidkbd_parse_desc(kbd, id, desc, dlen);
if (parserr != NULL) {
printf(: %s\n, parserr);
@@ -171,8 +174,8 @@
}
#ifdef DIAGNOSTIC
- printf(: %d modifier keys, %d key codes,
- kbd-sc_nmod, kbd-sc_nkeycode);
+ printf(: %d variable keys, %d key codes,
+ kbd-sc_nvar, kbd-sc_nkeycode);
#endif
kbd-sc_device = self;
@@ -245,6 +248,9 @@
if (kbd-sc_wskbddev != NULL)
rv = config_detach(kbd-sc_wskbddev, flags);
+ if (kbd-sc_var != NULL)
+ free(kbd-sc_var, M_DEVBUF);
+
return (rv);
}
@@ -263,11 +269,9 @@
}
#endif
- /* extract key modifiers */
- ud-modifiers = 0;
- for (i = 0; i kbd-sc_nmod; i++)
- if (hid_get_data(data, kbd-sc_modloc[i]))
- ud-modifiers |= kbd-sc_mods[i].mask;
+ /* extract variable keys */
+ for (i = 0; i kbd-sc_nvar; i++)
+ ud-var[i] = (u_int8_t)hid_get_data(data, kbd-sc_var[i].loc);
/* extract keycodes */
memcpy(ud-keycode, data + kbd-sc_keycodeloc.pos / 8,
@@ -311,7 +315,6 @@
void
hidkbd_decode(struct hidkbd *kbd, struct hidkbd_data *ud)
{
- uint32_t mod, omod;
u_int16_t ibuf[MAXKEYS];/* chars events */
int s;
int nkeys, i, j;
@@ -347,15 +350,15 @@
return; /* ignore */
}
nkeys = 0;
- mod = ud-modifiers;
- omod = kbd-sc_odata.modifiers;
- if (mod != omod)
- for (i = 0; i kbd-sc_nmod; i++)
- if (( mod kbd-sc_mods[i].mask) !=
- (omod kbd-sc_mods[i].mask))
- ADDKEY(kbd-sc_mods[i].key |
-(mod kbd-sc_mods[i].mask
- ? PRESS : RELEASE));
+
+ for (i = 0; i kbd-sc_nvar; i++)
+ if ((kbd-sc_odata.var[i] kbd-sc_var[i].mask) !=
+ (ud-var[i] kbd-sc_var[i].mask)) {
+ ADDKEY(kbd-sc_var[i].key |
+ ((ud-var[i] kbd-sc_var[i].mask) ?
+ PRESS : RELEASE));
+ }
+
if (memcmp(ud-keycode, kbd-sc_odata.keycode, kbd-sc_nkeycode) != 0) {
/* Check for released keys. */
for (i = 0; i kbd-sc_nkeycode; i++) {
@@ -547,10 +550,36 @@
{
struct hid_data *d;
struct hid_item h;
[xenocara] freetype-2.4.10
Hi, Here's an update to the latest freetype release (2.4.10). Please review, I'm a bit unsure about shlib_version bumping (major or minor?) Tested on amd64/sparc64. cheers! david [demime 1.01d removed an attachment of type application/x-gzip which had a name of freetype-2.4.10.diff.gz]
Re: [xenocara] freetype-2.4.10
On 2012/07/05 11:38, David Coppa wrote: On Thu, Jul 5, 2012 at 11:35 AM, Stuart Henderson s...@spacehopper.org wrote: On 2012/07/05 10:11, David Coppa wrote: Hi, Here's an update to the latest freetype release (2.4.10). Please review, I'm a bit unsure about shlib_version bumping (major or minor?) Tested on amd64/sparc64. cheers! david [demime 1.01d removed an attachment of type application/x-gzip which had a name of freetype-2.4.10.diff.gz] http://junkpile.org/freetype-2.4.10.diff
Re: Disable SSLv2 support for OpenSSL
- Original message - The diff below from sthen@ disables the SSLv2 support within the OpenSSL stack. All the browsers and almost all web servers / proxies and other apps do or have added their own bits of code over the years to explicitly disable the SSLv2 support and anything using SSL should be disabling SSLv2 anyway. It has been deprecated since 1996. With all of its security issues I think it would be best to disable the SSLv2 support all together within OpenSSL. This has been through ports bulks and a handful of ports were fixed due to the SSLv2 API removal. The ports tree is Ok now. Comments? OK? djm@ replied to my direct e-mail to him from a few days ago and said he had no objection to this going in. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [xenocara] freetype-2.4.10
On Thu, Jul 5, 2012 at 12:11 PM, Stuart Henderson s...@spacehopper.org wrote: On 2012/07/05 11:38, David Coppa wrote: On Thu, Jul 5, 2012 at 11:35 AM, Stuart Henderson s...@spacehopper.org wrote: On 2012/07/05 10:11, David Coppa wrote: Hi, Here's an update to the latest freetype release (2.4.10). Please review, I'm a bit unsure about shlib_version bumping (major or minor?) Tested on amd64/sparc64. cheers! david [demime 1.01d removed an attachment of type application/x-gzip which had a name of freetype-2.4.10.diff.gz] http://junkpile.org/freetype-2.4.10.diff Thanks a lot, Stuart ciao David
Re: New NVIDIA PCI ids
Date: Wed, 4 Jul 2012 10:40:55 -0400 From: Brad Smith b...@comstyle.com On Wed, Jul 04, 2012 at 04:27:45PM +0200, Mark Kettenis wrote: Date: Wed, 4 Jul 2012 04:20:40 -0400 From: Brad Smith b...@comstyle.com Some missing MCP89 PCI ids and another GeForce 320M PCI id. I left those MPC89 PCI ids intentionally. We have no clue what they actually are, so I don't see any point in adding them. Where did that GeForce 320M ID come from? from a dmesg. Mac mini. vga1 at pci5 dev 0 function 0 vendor NVIDIA, unknown product 0x08a4 rev 0xa2 Thanks for the clairifaction. Committed the GeForce 320M bit.
Re: New brgphy(4) PHY
On Wed, Jul 04, 2012 at 04:19:43PM +0200, Mark Kettenis wrote: Date: Wed, 4 Jul 2012 03:46:46 -0400 From: Brad Smith b...@comstyle.com Recognize BCM5717C, BCM5719C and BCM5720C PHY. ukphy2 at bge2 phy 3: Generic IEEE 802.3u media interface, rev. 0: OUI 0x00d897, model 0x0022 The rest came from FreeBSD. Index: miidevs === RCS file: /home/cvs/src/sys/dev/mii/miidevs,v retrieving revision 1.117 diff -u -p -r1.117 miidevs --- miidevs 19 Dec 2011 13:18:19 - 1.117 +++ miidevs 3 Jul 2012 04:11:50 - @@ -159,7 +159,10 @@ model xxBROADCOM2 BCM5709C 0x003c BCM570 model xxBROADCOM2 BCM5761 0x003d BCM5761 10/100/1000baseT PHY model xxBROADCOM2 BCM5709S 0x003f BCM5709S 1000/2500baseSX PHY model xxBROADCOM3 BCM57780 0x0019 BCM57780 10/100/1000baseT PHY +model xxBROADCOM3 BCM5717C 0x0020 BCM5717C 10/100/1000baseT PHY +model xxBROADCOM3 BCM5719C 0x0022 BCM5719C 10/100/1000baseT PHY model xxBROADCOM3 BCM57765 0x0024 BCM57765 10/100/1000baseT PHY +model xxBROADCOM3 BCM5720C 0x0036 BCM5720C 10/100/1000baseT PHY If the numbers in the BCM5718 Programmer's Guide are correct, you've swapped the BCM5717C and BCM5720C entries. Also, we really should keep these sorted in numerical order. I asked yongari@freebsd for confirmation and he claims these are the appropriate ids for BCM5717C and BCM5720C and he has sample boards. Anyway I don't really care if you keep them as is or flip them around since either way they're handled in the same manner. When we do see BCM5720's showing up which they will be since HP/Dell/IBM are using these dual-port chips its easy enough to flip them back (if necessary). Regarding the sorting... well they are and grouped by each respective OUI as the comment says relatively near the top of miidevs. * List of known models. Grouped by oui. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: bge(4) allow for adjustable PHY location
On Wed, Jul 04, 2012 at 03:45:12AM -0400, Brad Smith wrote: Allow the PHY location to be adjusted instead of it being hardcoded at 1 only. Add sanity checking for PHY location to the write register function. No change for currently supported chips. OK? and just FYI this is necessary as the newer chips no longer have the PHY at address 1. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
garbage collect USE_GCC3/TARGET_USE_GCC3/4
This garbage collects the USE_GCC3/TARGET_USE_GCC3/4 variables
within bsd.own.mk and Makefile.cross. I removed the last few
instances of USE_GCC3 within the ports tree a number of releases
ago and TARGET_USE_GCC3/4 was never used for anything.
Index: Makefile.cross
===
RCS file: /home/cvs/src/Makefile.cross,v
retrieving revision 1.50
diff -u -p -r1.50 Makefile.cross
--- Makefile.cross 12 Nov 2011 18:32:35 - 1.50
+++ Makefile.cross 10 Mar 2012 10:49:53 -
@@ -93,14 +93,10 @@ OLD_BINUTILS_ARCH=m68k m88k vax
.for _arch in ${TARGET_ARCH}
.if !empty(GCC2_ARCH:M${_arch})
-USE_GCC3?=no
-TARGET_USE_GCC3=No
COMPILER_VERSION?=gcc2
.elif !empty(GCC4_ARCH:M${_arch})
-TARGET_USE_GCC4=Yes
COMPILER_VERSION?=gcc4
.else
-TARGET_USE_GCC3=Yes
COMPILER_VERSION?=gcc3
.endif
Index: share/mk/bsd.own.mk
===
RCS file: /home/cvs/src/share/mk/bsd.own.mk,v
retrieving revision 1.114
diff -u -p -r1.114 bsd.own.mk
--- share/mk/bsd.own.mk 25 Nov 2011 05:25:25 - 1.114
+++ share/mk/bsd.own.mk 10 Mar 2012 10:50:52 -
@@ -38,12 +38,10 @@ BINUTILS217_ARCH=avr32 hppa64 ia64
.for _arch in ${MACHINE_ARCH}
.if !empty(GCC2_ARCH:M${_arch})
-USE_GCC3?=no
COMPILER_VERSION?=gcc2
.elif !empty(GCC4_ARCH:M${_arch})
COMPILER_VERSION?=gcc4
.else
-USE_GCC3?=yes
COMPILER_VERSION?=gcc3
.endif
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
