Re: [PATCH] add support for more Nuvoton chips to lm(4)
Hi Todd, Thanks for taking the time to review and offer improvements. I'm attaching a new diff that incorporates your suggestion for simplifying the matching and eliminating the unneeded struct and function. It is definitely a cleaner, simpler approach. I also corrected the whitespace issue you pointed out. I made a few tweaks to the voltage calculations. I actually spent quite a bit of time going down the rabbit hole here, and while I made some improvements, it is definitely not perfect yet. I removed the division by 2 from Vcore; I'm pretty confident this is correct, because I'm now seeing the voltage I expect, and the datasheet says: "The CPUVCORE pin feeds directly into the ADC with no voltage divider since the nominal voltage on this pin is only 1.2V." I actually installed Windows on this machine so I could run HWiNFO64 and see how the sensors looked there; I'm including a screenshot for your reference. Under Windows, it looks like the sensors are enumerated and displayed in the same order, though VBAT and VTT are skipped. Windows appears to have VIN2 and VIN3 labeled as +12V and +5V, though the values I see in HWiNFO64 are both slightly low and disagree with the values I see in the BIOS. With the current version of my patch, VIN3 looks correct and matches the BIOS value for +5V but VIN2 is low by a factor of about 3.5. I adjusted VIN4, VIN5 and VIN6 by dividing by 2; this brings their readings in line with what I see in HWiNFO64. >From what I've read from the Linux lm_sensors folks, it's a trial-and-error process to adjust these values correctly, and sometimes the readings are just garbage. As it stands, the patch is definitely better than not having sensors, and these values could always be tweaked with subsequent patches. If you have any suggestions for improvements here, please let me know. Thanks again for your help; I hope this patch is able to go in. Joe > Hello, > > On Fri, Dec 13, 2019 at 06:32:36PM -0500, Joe Gidi wrote: >> Hi all, >> >> I recently built a new system with an ASRock B450M Pro4 motherboard. > > I literally fired up a new system with the exact same board today and > saw the temp sensors didn't appear to be supported, so I'm very happy > that you posted this! > >> This board has a Nuvoton NCT6779D chip to monitor temperatures, fans and >> voltages. OpenBSD's lm(4) currently only supports the Nuvoton NCT6776F >> chip, added by Marco Pfatschbacher in 2011: >> >> https://marc.info/?l=openbsd-cvs=132318770131497=2 >> >> NetBSD's lm(4) gained support for several other Nuvoton chips in this >> commit by SAITOH Masanobu in 2017: >> >> http://mail-index.netbsd.org/source-changes/2017/07/11/msg086253.html >> >> I have adapted the NetBSD code to OpenBSD and confirmed that it appears >> to >> work correctly with my NCT6779D chip. With the attached patch, I get >> this >> in dmesg: >> >> wbsio0 at isa0 port 0x2e/2: NCT6779D rev 0x62 >> lm1 at wbsio0 port 0x290/8: NCT6779D >> >> And here's the sensor data: >> >> $ sysctl hw.sensors.lm1 >> hw.sensors.lm1.temp0=29.00 degC (MB Temperature) >> hw.sensors.lm1.temp1=31.00 degC (CPU Temperature) >> hw.sensors.lm1.temp2=78.00 degC (Aux Temp0) >> hw.sensors.lm1.temp3=98.00 degC (Aux Temp1) >> hw.sensors.lm1.temp4=22.50 degC (Aux Temp2) >> hw.sensors.lm1.temp5=-23.00 degC (Aux Temp3) >> hw.sensors.lm1.fan0=1095 RPM (System Fan) >> hw.sensors.lm1.fan1=739 RPM (CPU Fan) >> hw.sensors.lm1.fan2=400 RPM (Aux Fan0) >> hw.sensors.lm1.fan3=0 RPM (Aux Fan1) >> hw.sensors.lm1.fan4=387 RPM (Aux Fan2) >> hw.sensors.lm1.volt0=0.74 VDC (VCore) >> hw.sensors.lm1.volt1=2.16 VDC (VIN1) >> hw.sensors.lm1.volt2=3.33 VDC (AVCC) >> hw.sensors.lm1.volt3=3.33 VDC (+3.3V) >> hw.sensors.lm1.volt4=21.56 VDC (VIN0) >> hw.sensors.lm1.volt5=0.87 VDC (VIN8) >> hw.sensors.lm1.volt6=0.59 VDC (VIN4) >> hw.sensors.lm1.volt7=3.46 VDC (+3.3VSB) >> hw.sensors.lm1.volt8=0.00 VDC (VBAT) >> hw.sensors.lm1.volt9=0.00 VDC (VTT) >> hw.sensors.lm1.volt10=0.45 VDC (VIN5) >> hw.sensors.lm1.volt11=2.13 VDC (VIN6) >> hw.sensors.lm1.volt12=3.38 VDC (VIN2) >> hw.sensors.lm1.volt13=5.12 VDC (VIN3) >> hw.sensors.lm1.volt14=1.81 VDC (VIN7) >> >> The motherboard and CPU temperature values look very reasonable; the Aux >> Temp values look like garbage, possibly because there aren't any other >> sensors on this board? Fan values look reasonable. I am unsure about the >> voltage values, but the ones that claim to be 3.3 volts look sane. > > I see similar numbers with your patch applied. > > The BIOS doesn't show any other temperature values, so it is possble the > Aux Temp sensors aren't hooked up to an
[PATCH] add support for more Nuvoton chips to lm(4)
Hi all,
I recently built a new system with an ASRock B450M Pro4 motherboard. This
board has a Nuvoton NCT6779D chip to monitor temperatures, fans and
voltages. OpenBSD's lm(4) currently only supports the Nuvoton NCT6776F
chip, added by Marco Pfatschbacher in 2011:
https://marc.info/?l=openbsd-cvs=132318770131497=2
NetBSD's lm(4) gained support for several other Nuvoton chips in this
commit by SAITOH Masanobu in 2017:
http://mail-index.netbsd.org/source-changes/2017/07/11/msg086253.html
I have adapted the NetBSD code to OpenBSD and confirmed that it appears to
work correctly with my NCT6779D chip. With the attached patch, I get this
in dmesg:
wbsio0 at isa0 port 0x2e/2: NCT6779D rev 0x62
lm1 at wbsio0 port 0x290/8: NCT6779D
And here's the sensor data:
$ sysctl hw.sensors.lm1
hw.sensors.lm1.temp0=29.00 degC (MB Temperature)
hw.sensors.lm1.temp1=31.00 degC (CPU Temperature)
hw.sensors.lm1.temp2=78.00 degC (Aux Temp0)
hw.sensors.lm1.temp3=98.00 degC (Aux Temp1)
hw.sensors.lm1.temp4=22.50 degC (Aux Temp2)
hw.sensors.lm1.temp5=-23.00 degC (Aux Temp3)
hw.sensors.lm1.fan0=1095 RPM (System Fan)
hw.sensors.lm1.fan1=739 RPM (CPU Fan)
hw.sensors.lm1.fan2=400 RPM (Aux Fan0)
hw.sensors.lm1.fan3=0 RPM (Aux Fan1)
hw.sensors.lm1.fan4=387 RPM (Aux Fan2)
hw.sensors.lm1.volt0=0.74 VDC (VCore)
hw.sensors.lm1.volt1=2.16 VDC (VIN1)
hw.sensors.lm1.volt2=3.33 VDC (AVCC)
hw.sensors.lm1.volt3=3.33 VDC (+3.3V)
hw.sensors.lm1.volt4=21.56 VDC (VIN0)
hw.sensors.lm1.volt5=0.87 VDC (VIN8)
hw.sensors.lm1.volt6=0.59 VDC (VIN4)
hw.sensors.lm1.volt7=3.46 VDC (+3.3VSB)
hw.sensors.lm1.volt8=0.00 VDC (VBAT)
hw.sensors.lm1.volt9=0.00 VDC (VTT)
hw.sensors.lm1.volt10=0.45 VDC (VIN5)
hw.sensors.lm1.volt11=2.13 VDC (VIN6)
hw.sensors.lm1.volt12=3.38 VDC (VIN2)
hw.sensors.lm1.volt13=5.12 VDC (VIN3)
hw.sensors.lm1.volt14=1.81 VDC (VIN7)
The motherboard and CPU temperature values look very reasonable; the Aux
Temp values look like garbage, possibly because there aren't any other
sensors on this board? Fan values look reasonable. I am unsure about the
voltage values, but the ones that claim to be 3.3 volts look sane.
This is the first non-trivial patch I'm submitting and my C is pretty
rusty, so I would appreciate review and corrections. I don't have any
other systems with different Nuvoton chips to test, so I can't confirm
that this works for the other chips.
Could anyone please review this and help me get it into commit-ready shape?
Thanks,
Joe
--
Joe Gidi
j...@entropicblur.com
"You cannot buy skill." -- Ross SeyfriedIndex: share/man/man4/lm.4
===
RCS file: /cvs/src/share/man/man4/lm.4,v
retrieving revision 1.25
diff -u -p -u -r1.25 lm.4
--- share/man/man4/lm.4 16 Jul 2013 16:05:49 - 1.25
+++ share/man/man4/lm.4 13 Dec 2019 22:49:02 -
@@ -82,7 +82,7 @@ National Semiconductor LM79
.It
National Semiconductor LM81
.It
-Nuvoton NCT6776F
+Nuvoton NCT6775F, NCT6776F, NCT6779D, NCT6791D, NCT6792D, NCT6793D, NCT6795D
.It
Winbond W83627HF, W83627THF, W83637HF and W83697HF
.It
Index: sys/dev/ic/lm78.c
===
RCS file: /cvs/src/sys/dev/ic/lm78.c,v
retrieving revision 1.24
diff -u -p -u -r1.24 lm78.c
--- sys/dev/ic/lm78.c 14 Mar 2015 03:38:47 - 1.24
+++ sys/dev/ic/lm78.c 13 Dec 2019 22:49:03 -
@@ -67,6 +67,7 @@ void wb_refresh_temp(struct lm_softc *,
void wb_refresh_fanrpm(struct lm_softc *, int);
void wb_nct6776f_refresh_fanrpm(struct lm_softc *, int);
void wb_w83792d_refresh_fanrpm(struct lm_softc *, int);
+const char * wb_nct67xx_id2str(uint8_t);
void as_refresh_temp(struct lm_softc *, int);
@@ -80,6 +81,20 @@ struct lm_chip lm_chips[] = {
{ def_match } /* Must be last */
};
+struct {
+ uint8_t id;
+ const char *str;
+} nct_chips[] = {
+ {WBSIO_ID_NCT6775F, "NCT6775F"},
+ {WBSIO_ID_NCT6776F, "NCT6776F"},
+ {WBSIO_ID_NCT5104D, "NCT5104D or 610[246]D"},
+ {WBSIO_ID_NCT6779D, "NCT6779D"},
+ {WBSIO_ID_NCT6791D, "NCT6791D"},
+ {WBSIO_ID_NCT6792D, "NCT6792D"},
+ {WBSIO_ID_NCT6793D, "NCT6793D"},
+ {WBSIO_ID_NCT6795D, "NCT6795D"},
+};
+
struct lm_sensor lm78_sensors[] = {
/* Voltage */
{ "VCore A", SENSOR_VOLTS_DC, 0, 0x20, lm_refresh_volt, RFACT_NONE },
@@ -215,6 +230,43 @@ struct lm_sensor nct6776f_sensors[] = {
{ NULL }
};
+/* NCT6779D */
+struct lm_sensor nct6779d_sensors[] = {
+ /* Voltage */
+ { "VCore", SENSOR_VOLTS_DC, 4, 0x80, lm_refresh_volt, RFACT_NONE / 2 },
+ { "VIN1", SENSOR_VOLTS_DC, 4, 0x81, lm_refresh_volt, RFACT(56, 10) / 2 },
+ { "AVCC", SENSOR_VOLTS_DC, 4, 0x82, lm_refresh_volt, RFACT(34, 34) / 2 },
+ { "+3.3V", SENSOR_VOLTS_DC, 4, 0x83, lm_refresh_volt, RFACT(34, 34) / 2 },
+ { "VIN0", SENSOR_VOLTS_DC, 4, 0x84, lm_refresh_volt, RFACT(48600, 1) },
+ { "VIN8", SENSOR_VOLTS_DC, 4, 0x85, lm_refresh_volt, RF
[PATCH] run security(8) on first boot
I did a couple of fresh installs the other day, which reminded me of a
minor irritation and prompted me to think about a possible solution.
The first run of security(8) on a fresh install is not terribly helpful.
It produces a huge email report since it diffs all the /etc/changelist
files against /dev/null. If you're already familiar with OpenBSD and
understand this behavior, you probably disregard this email and drive on.
If you're a new user, this is probably surprising and somewhat misleading.
After all, you've just installed an operating system that takes
justifiable pride in sane, secure defaults, and the next morning you
receive a multi-thousand-line insecurity report that calls out every
important configuration file on the system.
I think the simplest way to prevent this would be for install.sub to add a
line to /etc/rc.firsttime that runs security(8) and discards the output,
or perhaps logs it to a file, rather than emailing it. This would "prime
the pump" by populating /var/backups with as-installed copies of the
changelist files, and then the first nightly run of security(8) would only
show files that have actually been changed post-install.
Of course, this also means you have virgin copies of your config files
stashed away immediately, in case you need one before the nightly
security(8) run can back them up for you.
This will make the first boot take longer, perhaps by several minutes on
slower platforms. Of course, the first boot is already slower due to key
generation, etc.
Diff below was tested in an amd64 bsd.rd and seems to behave as expected.
I have *not* built a full release or tested every possible use case; I
know there are sometimes issues with space on some install media, and
hopefully this small addition would not cause an overflow.
Does anyone see value in this? If not, I suppose it might end up living in
my install.site.
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1031
diff -u -p -r1.1031 install.sub
--- install.sub 28 Jul 2017 18:15:44 - 1.1031
+++ install.sub 29 Jul 2017 21:03:03 -
@@ -2976,6 +2976,9 @@ do_install() {
print -r -- "$_rootkey" >>/mnt/root/.ssh/authorized_keys
)
+ # Run security(8) on first boot to populate /var/backups
+ echo "/usr/libexec/security > /dev/null" >> /mnt/etc/rc.firsttime
+
# Perform final steps common to both an install and an upgrade.
finish_up
}
Re: patch: fix inteldrm for Intel P4000 graphics
>> Date: Tue, 4 Jul 2017 17:24:27 -0400 >> From: "Joe Gidi" <j...@entropicblur.com> >> >> I have a machine with a Xeon E3-1225v2 CPU, which includes integrated >> Intel P4000 graphics. This required a patch back in 2015 to avoid >> matching >> on the mythical "Intel Quanta Transcode" device, which kettenis@ >> committed >> here: >> >> http://marc.info/?l=openbsd-cvs=144342287923444=2 >> >> The recent update to inteldrm broke X on this system, because this patch >> got lost. >> >> The patch below has been tested and restores inteldrm functionality with >> P4000 graphics. > > Thanks. Fixed this in a different way such that it hopefully doesn't > happen again. Can you let me know if the problem persists? The fix you committed is working for me. Thank you! -- Joe Gidi j...@entropicblur.com "You cannot buy skill." -- Ross Seyfried
patch: fix inteldrm for Intel P4000 graphics
I have a machine with a Xeon E3-1225v2 CPU, which includes integrated Intel P4000 graphics. This required a patch back in 2015 to avoid matching on the mythical "Intel Quanta Transcode" device, which kettenis@ committed here: http://marc.info/?l=openbsd-cvs=144342287923444=2 The recent update to inteldrm broke X on this system, because this patch got lost. The patch below has been tested and restores inteldrm functionality with P4000 graphics. Thanks, -- Joe Gidi j...@entropicblur.com Index: i915_drv.c === RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v retrieving revision 1.103 diff -u -p -u -r1.103 i915_drv.c --- i915_drv.c 1 Jul 2017 16:14:10 - 1.103 +++ i915_drv.c 4 Jul 2017 21:13:48 - @@ -424,7 +424,6 @@ static const struct intel_device_info in INTEL_IRONLAKE_M_IDS(_ironlake_m_info), \ INTEL_SNB_D_IDS(_sandybridge_d_info), \ INTEL_SNB_M_IDS(_sandybridge_m_info), \ - INTEL_IVB_Q_IDS(_ivybridge_q_info), /* must be first IVB */ \ INTEL_IVB_M_IDS(_ivybridge_m_info), \ INTEL_IVB_D_IDS(_ivybridge_d_info), \ INTEL_HSW_D_IDS(_haswell_d_info), \
Re: Radeon HD 4350 variant diff
On Thu, May 26, 2011 8:55 pm, Joe Gidi wrote:
Last week I picked up another Radeon HD 4350 card, expecting it to just
work like another 4350 I own. For whatever reason, the new card (same
manufacturer, same part number) has a different PCI ID and didn't work
until I patched in support for it.
I wasn't exactly sure what to call this new card; both Xenocara's
ati_pciids.csv file and the latest ati_pciids.csv from upstream call this
product ID an ATI Mobility Radeon 4300 Series.I went with Mobility
Radeon HD 4350, although my particular card is a regular PCI-E card for a
desktop PC.
In any case, the card is tested and works fine once the PCI ID is added,
and Xenocara already knows about it. Any developers willing to take a look
at this? I believe the flags are correct, though I can see it might be
misleading to call it a Mobility and not have RADEON_IS_MOBILITY in
the flags.
Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1602
diff -u -r1.1602 pcidevs
--- sys/dev/pci/pcidevs 22 May 2011 18:34:42 - 1.1602
+++ sys/dev/pci/pcidevs 27 May 2011 00:36:43 -
@@ -1338,6 +1338,7 @@
product ATI RADEON_HD38500x9505 Radeon HD 3850
product ATI RADEON_HD45500x9540 Radeon HD 4550
product ATI RADEON_HD43500x954f Radeon HD 4350
+product ATI RADEON_HD4350_M 0x9552 Mobility Radeon HD 4350
product ATI RADEON_HD4500_M 0x9553 Mobility Radeon HD 4500
product ATI RADEON_HD2600_M760x9581 Mobility Radeon HD 2600
product ATI RADEON_HD2600PROAGP 0x9587 Radeon HD 2600 Pro AGP
Index: sys/dev/pci/drm/radeon_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon_drv.c,v
retrieving revision 1.53
diff -u -r1.53 radeon_drv.c
--- sys/dev/pci/drm/radeon_drv.c 2 May 2011 10:22:13 - 1.53
+++ sys/dev/pci/drm/radeon_drv.c 27 May 2011 00:36:43 -
@@ -510,6 +510,8 @@
CHIP_RS780|RADEON_NEW_MEMMAP|RADEON_IS_IGP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4350,
CHIP_RV710|RADEON_NEW_MEMMAP},
+ {PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4350_M,
+ CHIP_RV710|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4500_M,
CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4650,
--
Joe Gidi
j...@entropicblur.com
You cannot buy skill. -- Ross Seyfried
Apparently this should be a Mobility Radeon HD 4330; correct diff follows.
I have no idea why this HD 4350 PCI-E card thinks it belongs in a laptop,
but hardware makers do strange things...
Index: src/sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1609
diff -u -r1.1609 pcidevs
--- src/sys/dev/pci/pcidevs 29 May 2011 20:24:21 - 1.1609
+++ src/sys/dev/pci/pcidevs 30 May 2011 21:06:19 -
@@ -1358,6 +1358,7 @@
product ATI RADEON_HD3850 0x9505 Radeon HD 3850
product ATI RADEON_HD4550 0x9540 Radeon HD 4550
product ATI RADEON_HD4350 0x954f Radeon HD 4350
+product ATI RADEON_HD4330_M0x9552 Mobility Radeon HD 4330
product ATI RADEON_HD4500_M0x9553 Mobility Radeon HD 4500
product ATI RADEON_HD2600_M76 0x9581 Mobility Radeon HD 2600
product ATI RADEON_HD2600PROAGP0x9587 Radeon HD 2600 Pro AGP
Index: src/sys/dev/pci/drm/radeon_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon_drv.c,v
retrieving revision 1.53
diff -u -r1.53 radeon_drv.c
--- src/sys/dev/pci/drm/radeon_drv.c2 May 2011 10:22:13 - 1.53
+++ src/sys/dev/pci/drm/radeon_drv.c30 May 2011 21:06:19 -
@@ -510,6 +510,8 @@
CHIP_RS780|RADEON_NEW_MEMMAP|RADEON_IS_IGP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4350,
CHIP_RV710|RADEON_NEW_MEMMAP},
+ {PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4330_M,
+ CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4500_M,
CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4650,
--
Joe Gidi
j...@entropicblur.com
You cannot buy skill. -- Ross Seyfried
Radeon HD 4350 variant diff
Last week I picked up another Radeon HD 4350 card, expecting it to just
work like another 4350 I own. For whatever reason, the new card (same
manufacturer, same part number) has a different PCI ID and didn't work
until I patched in support for it.
I wasn't exactly sure what to call this new card; both Xenocara's
ati_pciids.csv file and the latest ati_pciids.csv from upstream call this
product ID an ATI Mobility Radeon 4300 Series.I went with Mobility
Radeon HD 4350, although my particular card is a regular PCI-E card for a
desktop PC.
In any case, the card is tested and works fine once the PCI ID is added,
and Xenocara already knows about it. Any developers willing to take a look
at this? I believe the flags are correct, though I can see it might be
misleading to call it a Mobility and not have RADEON_IS_MOBILITY in
the flags.
Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1602
diff -u -r1.1602 pcidevs
--- sys/dev/pci/pcidevs 22 May 2011 18:34:42 - 1.1602
+++ sys/dev/pci/pcidevs 27 May 2011 00:36:43 -
@@ -1338,6 +1338,7 @@
product ATI RADEON_HD3850 0x9505 Radeon HD 3850
product ATI RADEON_HD4550 0x9540 Radeon HD 4550
product ATI RADEON_HD4350 0x954f Radeon HD 4350
+product ATI RADEON_HD4350_M0x9552 Mobility Radeon HD 4350
product ATI RADEON_HD4500_M0x9553 Mobility Radeon HD 4500
product ATI RADEON_HD2600_M76 0x9581 Mobility Radeon HD 2600
product ATI RADEON_HD2600PROAGP0x9587 Radeon HD 2600 Pro AGP
Index: sys/dev/pci/drm/radeon_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon_drv.c,v
retrieving revision 1.53
diff -u -r1.53 radeon_drv.c
--- sys/dev/pci/drm/radeon_drv.c2 May 2011 10:22:13 - 1.53
+++ sys/dev/pci/drm/radeon_drv.c27 May 2011 00:36:43 -
@@ -510,6 +510,8 @@
CHIP_RS780|RADEON_NEW_MEMMAP|RADEON_IS_IGP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4350,
CHIP_RV710|RADEON_NEW_MEMMAP},
+ {PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4350_M,
+ CHIP_RV710|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4500_M,
CHIP_RV710|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP},
{PCI_VENDOR_ATI, PCI_PRODUCT_ATI_RADEON_HD4650,
--
Joe Gidi
j...@entropicblur.com
You cannot buy skill. -- Ross Seyfried
Add Xbox 360 Controller USB support
This is taken pretty much straight from FreeBSD ( see
http://marc.info/?l=freebsd-commits-allm=113600388101707w=2 ). It is
tested and working on my amd64 box. Some usbhidctl output:
Generic_Desktop:Game_Pad.Generic_Desktop:Pointer.Generic_Desktop:D-pad_Up=0
Generic_Desktop:Game_Pad.Generic_Desktop:Pointer.Generic_Desktop:D-pad_Down=0
Generic_Desktop:Game_Pad.Generic_Desktop:Pointer.Generic_Desktop:D-pad_Left=0
Generic_Desktop:Game_Pad.Generic_Desktop:Pointer.Generic_Desktop:D-pad_Right=0
Generic_Desktop:Game_Pad.Button:Button_8=0
Generic_Desktop:Game_Pad.Button:Button_7=0
Generic_Desktop:Game_Pad.Button:Button_9=0
Generic_Desktop:Game_Pad.Button:Button_10=0
Generic_Desktop:Game_Pad.Button:Button_5=0
Generic_Desktop:Game_Pad.Button:Button_6=0
Generic_Desktop:Game_Pad.Button:Button_11=0
Generic_Desktop:Game_Pad.Button:Button_1=1
Generic_Desktop:Game_Pad.Button:Button_2=0
Generic_Desktop:Game_Pad.Button:Button_3=0
Generic_Desktop:Game_Pad.Button:Button_4=0
Generic_Desktop:Game_Pad.Generic_Desktop:Z=0
Generic_Desktop:Game_Pad.Generic_Desktop:Rz=0
Generic_Desktop:Game_Pad.Generic_Desktop:X=-4169
Generic_Desktop:Game_Pad.Generic_Desktop:Y=-2390
Generic_Desktop:Game_Pad.Generic_Desktop:Rx=-432
Generic_Desktop:Game_Pad.Generic_Desktop:Ry=1363
Any devs interested in reviewing and hopefully committing this?
--
Joe Gidi
j...@entropicblur.com
You cannot buy skill. -- Ross Seyfried
--- uhidev.c.orig Mon Nov 8 01:57:09 2010
+++ uhidev.cMon Nov 8 01:08:30 2010
@@ -55,8 +55,9 @@
#include dev/usb/uhidev.h
-/* Report descriptor for broken Wacom Graphire */
+/* Replacement report descriptors for devices shipped with broken ones */
#include dev/usb/ugraphire_rdesc.h
+#include dev/usb/uxb360gp_rdesc.h
#ifdef UHIDEV_DEBUG
#define DPRINTF(x) do { if (uhidevdebug) printf x; } while (0)
@@ -99,8 +100,15 @@
if (uaa-iface == NULL)
return (UMATCH_NONE);
id = usbd_get_interface_descriptor(uaa-iface);
- if (id == NULL || id-bInterfaceClass != UICLASS_HID)
- return (UMATCH_NONE);
+if (id == NULL)
+return (UMATCH_NONE);
+if (id-bInterfaceClass != UICLASS_HID) {
+/* The Xbox 360 gamepad doesn't use the HID class. */
+if (id-bInterfaceClass != UICLASS_VENDOR ||
+id-bInterfaceSubClass != UISUBCLASS_XBOX360_CONTROLLER ||
+id-bInterfaceProtocol != UIPROTO_XBOX360_GAMEPAD)
+return (UMATCH_NONE);
+}
if (usbd_get_quirks(uaa-device)-uq_flags UQ_BAD_HID)
return (UMATCH_NONE);
if (uaa-matchlvl)
@@ -203,7 +211,14 @@
/* Keep descriptor */
break;
}
+ } else if (id-bInterfaceClass == UICLASS_VENDOR
+ id-bInterfaceSubClass == UISUBCLASS_XBOX360_CONTROLLER
+ id-bInterfaceProtocol == UIPROTO_XBOX360_GAMEPAD) {
+ /* The Xbox 360 gamepad has no report descriptor. */
+ size = sizeof uhid_xb360gp_report_descr;
+ descptr = uhid_xb360gp_report_descr;
}
+
if (descptr) {
desc = malloc(size, M_USBDEV, M_NOWAIT);
--- usb.h.orig Mon Nov 8 01:58:09 2010
+++ usb.h Mon Nov 8 00:42:01 2010
@@ -486,7 +486,8 @@
#define UIPROTO_IRDA 0
#define UICLASS_VENDOR 0xff
-
+#define UISUBCLASS_XBOX360_CONTROLLER 0x5d
+#define UIPROTO_XBOX360_GAMEPAD 0x01
#define USB_HUB_MAX_DEPTH 5
/*-
* Copyright (c) 2005 Ed Schouten e...@freebsd.org
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD: src/sys/dev/usb/uxb360gp_rdesc.h,v 1.3 2008/05/24 18:35:55 ed Exp
