Re: uwacom: reduce tip pressure for click activation
Thanks for the patch! Unfortunately I'm using the tablet anymore and are not able to test this. This pressure level was chosen because the Linux driver uses it as well: https://github.com/linuxwacom/input-wacom/blob/master/4.5/wacom_wac.c#L297 I have no technical knowledge on how this works, but could it be that the pressure levels can be a kind of between tables of the same model? I seem to remember that levels such as the one you propose didn't work for me. Note that there are in total 255 pressure levels, so level 10 shouldn't be "pressing very hard", it was enough to just let the pen tip rest on the tablet. Frank
Using shift on external keyboards in softraid passphrases from efiboot
Hello all,
I haven't been able to type the passphrase of my softraid device on boot when
using an external keyboard on my Thinkpad X260. Finally I had some time to
debug this problem and this is what I discovered.
On a different laptop with EFI, the ReadKeyStroke call will not return a packet
when shift is pressed on the external keyboard. On the Thinkpad however, a
packet is returned with UnicodeChar == 0, which results in a wrong passphrase
being used.
This seems like a bug in the firmware to me, because according to some EFI
specifications I found online, this should not return a packet. I've attached a
simple patch that fixes this, but I'm not sure whether this might break things
on different systems.
--
Frank
Index: efiboot.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/efiboot.c,v
retrieving revision 1.30
diff -u -p -r1.30 efiboot.c
--- efiboot.c 6 Jul 2018 07:55:50 - 1.30
+++ efiboot.c 16 Aug 2018 19:44:50 -
@@ -494,7 +494,7 @@ efi_cons_getc(dev_t dev)
}
status = EFI_CALL(conin->ReadKeyStroke, conin, );
- while (status == EFI_NOT_READY) {
+ while (status == EFI_NOT_READY || key.UnicodeChar == 0) {
if (dev & 0x80)
return (0);
EFI_CALL(BS->WaitForEvent, 1, >WaitForKey, );
Re: CVS: cvs.openbsd.org: src
On Mon, Jul 3, 2017, at 08:30, Martijn van Duren wrote: > This change *STILL* breaks my $DAYJOB machine. > > dmesg with DRMDEBUG enabled Maybe you shouldn't chose Apple hardware ;-) Works great here on a Thinkpad X260 Mark, thank you very much! Frank
Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work
On Mon, Sep 12, 2016 at 10:18:14AM +0200, Martin Pieuchot wrote: > > I just committed your driver, with some tweaks in the manpage. Great, thank you! > > It is quite likely related to this discussion: > > > > http://marc.info/?l=openbsd-misc=140529029513846=2 > > http://marc.info/?l=openbsd-misc=140589215905202=2 > > http://marc.info/?l=openbsd-misc=141676273919602=2 > > Indeed. This is a common issue to all WSMOUSE_TYPE_TPANEL pointers. > > If you're interested in fixing this problem you should look at X11 > ws(4) driver. If you can modify the driver and the wscons(4) layer > such that it isn't necessary to open a different node to calibrate > your device then plugging a device after starting a Xserver wouldn't > be a problem. Thanks for the pointers, that is most probably the cause indeed. I'll try to dig into this. Is the solution you propose the best one, or would it also be possible to let the ws driver reopen the device on a failed read and fix it like that? Frank
Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work
On Thu, Sep 08, 2016 at 07:44:33PM +0200, Ulf Brosziewski wrote: > Maybe one day I'll get it right: > s/wsmouse_input_sync()/wsmouse_input_sync(ms->sc_wsmousedev)/ Haha, you did get it right indeed. Attached my working updated patch, with your suggested API usage. Looks cleaner like this. I've also made some progress regarding the scaling bug. It seems the device is not properly detached from Xorg when it is unplugged, because the log starts getting spammed with loads of messages like this: [ 202.482] (EE) ws: wacom: read error Input/output error When I create an xorg.conf that only contains the wsmouse device of the Wacom tablet and disabled all other wsmouse devices, I cannot controle the device anymore after plugging it in again. Without the xorg.conf I can control it, but with the wrong scale. I think this difference is caused by the fact that the "all containing" /dev/wsmouse is still passing data to Xorg for the Wacom device, but the tablet specific /dev/wsmouse1 device is not. Switchting to a console somehow forces Xorg to reopen the /dev/wsmouse1 device which results in a working mouse pointer (or in good scaled mouse pointer movement in the case of not using an xorg.conf file to disable other wsmouse devices). Does anybody see why the ws driver start to print these errors? Am I missing an important call on detachment? Thanks. Frank Index: share/man/man4/uwacom.4 === RCS file: share/man/man4/uwacom.4 diff -N share/man/man4/uwacom.4 --- /dev/null 1 Jan 1970 00:00:00 - +++ share/man/man4/uwacom.4 5 Sep 2016 18:36:32 - @@ -0,0 +1,60 @@ +.\" $OpenBSD$ +.\" +.\" Copyright (c) 2016 Frank Groeneveld <fr...@frankgroeneveld.nl> +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and this permission notice appear in all copies. +.\" +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCAIMS ALL WARRANTIES +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\" +.Dd $Mdocdate: September 5 2016 $ +.Dt UWACOM 4 +.Os +.Sh NAME +.Nm uwacom +.Nd Wacom USB tablets +.Sh SYNOPSIS +.Cd "uwacom* at uhidev?" +.Cd "wsmouse* at uwacom? mux 0" +.Sh DESCRIPTION +The +.Nm +driver provides basic support for Wacom USB tablets. +Access to these devices is through the +.Xr wscons 4 +framework. +.Pp +Absolute positioning of the mouse cursor can be done by hovering the pen above the tablet. Touching the tablet with the pen tip will emulate mouse button 0, while the two pen buttons will emulate button 1 and button 2. +.Pp +The +.Nm +driver supports the following Wacom tablets: +.Pp +.Bl -column "Intuos Draw" "Model Number" -offset 6n +.It Em Name Ta Model Number +.It Li Intuos Draw Ta CTL-490 +.Sh SEE ALSO +.Xr uhidev 4 , +.Xr usb 4 , +.Xr wsmouse 4 +.Sh HISTORY +The +.Nm +driver +first appeared in +.Ox 6.1 . +.Sh AUTHORS +.An -nosplit +The +.Nm +driver was written by +.An Frank Groeneveld fr...@frankgroeneveld.nl . +.Sh BUGS +To make axis scaling work correctly, the device should be plugged in when X starts. Advanced features such as pen tip pressure are not supported. Index: sys/arch/amd64/conf/GENERIC === RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v retrieving revision 1.432 diff -u -p -r1.432 GENERIC --- sys/arch/amd64/conf/GENERIC 4 Sep 2016 10:22:05 - 1.432 +++ sys/arch/amd64/conf/GENERIC 5 Sep 2016 18:36:32 - @@ -244,6 +244,8 @@ umass* at uhub?# USB Mass Storage devi ubcmtp*at uhub?# Broadcom USB trackpad wsmouse* at ubcmtp? mux 0 uhidev*at uhub?# Human Interface Devices +uwacom*at uhidev? # USB Wacom tablet +wsmouse* at uwacom? mux 0 ums* at uhidev? # USB mouse wsmouse* at ums? mux 0 uts* at uhub?# USB touchscreen Index: sys/dev/hid/hid.h === RCS file: /cvs/src/sys/dev/hid/hid.h,v retrieving revision 1.4 diff -u -p -r1.4 hid.h --- sys/dev/hid/hid.h 20 Jan 2016 01:26:00 - 1.4 +++ sys/dev/hid/hid.h 5 Sep 2016 18:36:32 - @@ -127,6 +127,7 @@ int hid_is_collection(const void *, int, #define HUP_MICROSOFT 0xff00 /* XXX compat */ #define HUP_APPLE
Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work
On Wed, Sep 07, 2016 at 12:12:43AM +0200, Ulf Brosziewski wrote:
> Hi, I was a bit hasty, I should have mentioned that calling
> wsmouse_input_sync is required here. The equivalent of your
> code would would be this:
>
> if (x != 0 || y != 0 || buttons != ms->sc_buttons) {
> wsmouse_position(ms->sc_wsmousedev, x, y);
> /* ignore proximity, it will cause invalid button 2 events */
> if ((data[0] & 0xf0) != 0xc0)
> wsmouse_buttons(ms->sc_wsmousedev, buttons);
> wsmouse_input_sync();
> }
>
> The WSMOUSE_INPUT macro - a substitute for the old wsmouse_input
> function - does include that call (see wsmousevar.h).
>
> There is a set of functions for reporting input states:
> wsmouse_buttons, wsmouse_motion, wsmouse_position, wsmouse_touch,
> and wsmouse_mtstate (and the somewhat special wsmouse_set and
> wsmouse_mtframe). A driver can call them in any order, and it
> doesn't need to check whether there are deltas, wsmouse does
> this anyway. However, a frame must be finished by a call to
> wsmouse_input_sync. It is this function that generates the
> wscons events.
>
> The new interface has been introduced in 6.0.
>
That explains, thanks you very much for the detailed reply. My sources
were less than a week old, so it will probably just work with the sync
call.
I'll probably send an updated diff when I've fixed the scaling issue.
Frank
Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work
On Tue, Sep 06, 2016 at 02:19:28PM +0200, Ulf Brosziewski wrote: > Just a remark on your use of the wsmouse interface (which isn't well > known and documented yet): wsmouse_set is a function for uncommon > cases. To report a pair of absolute coordinates use wsmouse_position, > that is, instead of > wsmouse_set(ms->sc_wsmousedev, WSMOUSE_ABS_X, x, 0); > wsmouse_set(ms->sc_wsmousedev, WSMOUSE_ABS_Y, y, 0); > you should use > wsmouse_position(ms->sc_wsmousedev, x, y); > Likewise, for reporting the button state there is > wsmouse_buttons(ms->sc_wsmousedev, buttons); > There is no need for the WSMOUSE_INPUT macro here. Seems like a cleaner API indeed, but those functions don't seem to work for me. Both mouse movement and button reporting stop functioning when replaced by those calls. How old is this API, might it be some outdated sources on my side? Something else I'm doing wrong? Frank
Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work
On Wed, Aug 10, 2016 at 03:42:34PM +0200, Martin Pieuchot wrote:
> I'd ignore it as a first step, then revisit this later.
Attached a first stab at a seperate driver. Some points of interest:
- I've decided against using a custom hid descriptor, but instead define
the needed inputs in the driver. This seems more readable to me.
- Driver attaches to one uhid, but there are three uhidev devices and
numerous uhids in this device, including a non-working uhid that ums
attaches to (ums0 in the attached dmesg output).
- One bug still left: when the device is attached after X has started,
it seems the scaling is done wrongly. I had this problem with the
hacked ums driver as well. Most of the time it is fixed by switching
between console and X.
- Documentation is still absent, I'll gladly write it when you guys
apporve of the code I wrote.
What do you guys think? Any comments or suggestions? Any ideas on how to
attach to all three uhidevs?
Thanks.
Frank
Index: hid/hid.h
===
RCS file: /cvs/src/sys/dev/hid/hid.h,v
retrieving revision 1.4
diff -u -p -r1.4 hid.h
--- hid/hid.h 20 Jan 2016 01:26:00 - 1.4
+++ hid/hid.h 3 Sep 2016 13:09:24 -
@@ -127,6 +127,7 @@ int hid_is_collection(const void *, int,
#define HUP_MICROSOFT 0xff00
/* XXX compat */
#define HUP_APPLE 0x00ff
+#define HUP_WACOM 0xff00
/* Usages, Power Device */
#define HUP_INAME 0x0001
Index: usb/files.usb
===
RCS file: /cvs/src/sys/dev/usb/files.usb,v
retrieving revision 1.129
diff -u -p -r1.129 files.usb
--- usb/files.usb 27 Jun 2016 11:42:47 - 1.129
+++ usb/files.usb 3 Sep 2016 13:09:25 -
@@ -446,3 +446,8 @@ filedev/usb/uberry.cuberry
device upd: hid
attach upd at uhidbus
file dev/usb/upd.c upd
+
+# Wacom tablets
+device uwacom: hid, hidms, wsmousedev
+attach uwacom at uhidbus
+file dev/usb/uwacom.cuwacom
Index: usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.666
diff -u -p -r1.666 usbdevs
--- usb/usbdevs 1 Jun 2016 09:48:20 - 1.666
+++ usb/usbdevs 3 Sep 2016 13:09:25 -
@@ -4397,6 +4397,7 @@ product WACOM GRAPHIRE0x0010 Graphire
product WACOM GRAPHIRE3_4X50x0013 Graphire3 4x5
product WACOM GRAPHIRE4_4X50x0015 Graphire4 Classic A6
product WACOM INTUOSA5 0x0021 Intuos A5
+product WACOM INTUOSS2 0x033b Intuos S 2 (CTL-490)
/* WAGO Kontakttechnik products */
product WAGO SERVICECABLE 0x07a6 Service Cable 750-923
Index: usb/usbdevs.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.678
diff -u -p -r1.678 usbdevs.h
--- usb/usbdevs.h 1 Jun 2016 09:48:54 - 1.678
+++ usb/usbdevs.h 3 Sep 2016 13:09:25 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.678 2016/06/01 09:48:54 mglocker Exp $ */
+/* $OpenBSD$ */
/*
* THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
@@ -4404,6 +4404,7 @@
#defineUSB_PRODUCT_WACOM_GRAPHIRE3_4X5 0x0013 /* Graphire3
4x5 */
#defineUSB_PRODUCT_WACOM_GRAPHIRE4_4X5 0x0015 /* Graphire4
Classic A6 */
#defineUSB_PRODUCT_WACOM_INTUOSA5 0x0021 /* Intuos A5 */
+#defineUSB_PRODUCT_WACOM_INTUOSS2 0x033b /* Intuos S 2
(CTL-490) */
/* WAGO Kontakttechnik products */
#defineUSB_PRODUCT_WAGO_SERVICECABLE 0x07a6 /* Service
Cable 750-923 */
Index: usb/usbdevs_data.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.672
diff -u -p -r1.672 usbdevs_data.h
--- usb/usbdevs_data.h 1 Jun 2016 09:48:54 - 1.672
+++ usb/usbdevs_data.h 3 Sep 2016 13:09:25 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.672 2016/06/01 09:48:54 mglocker Exp $
*/
+/* $OpenBSD$ */
/*
* THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT.
@@ -11208,6 +11208,10 @@ const struct usb_known_product usb_known
{
USB_VENDOR_WACOM, USB_PRODUCT_WACOM_INTUOSA5,
"Intuos A5",
+ },
+ {
+ USB_VENDOR_WACOM, USB_PRODUCT_WACOM_INTUOSS2,
+ "Intuos S 2 (CTL-490)",
},
{
USB_VENDOR_WAGO, USB_PRODUCT_WAGO_SERVICECABLE,
Index: usb/uwacom.c
===
RCS file: usb/uwacom.c
diff -N usb/uwacom.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ usb/uwacom.c3 Sep 2016 13:09:25 -
@@ -0,0 +1,233 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2016 Frank Groeneveld <fr...@frankgroeneveld.nl>
+ *
+ * Pe
Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work
On Mon, Aug 08, 2016 at 02:31:41PM +0200, Martin Pieuchot wrote: > > Search for UHIDEV_CLAIM_ALLREPORTID, at least upd(4) uses it. I've tried to implement a simple driver using this technique and it seems this can only be used to claim all report_ids under one uhidev device. The tablet acts as three though, with the usefull info being under the first and a non-working wsmouse attaches to the a report_id under the last uhidev. Would it be possible to claims these as well? Or should I just make it work under the first uhidev and ignore the fact that a non-working wsmouse is attached? Thanks again for your help. Frank
Re: Fix Wacom Intuos S 2 descriptor and make wsmouse work
On Mon, Aug 08, 2016 at 11:12:02AM +0200, Martin Pieuchot wrote: > > ... > > Is the attached patch acceptable? Or would it be better to write a > > seperate driver, such as uwacom, that does the same as ums, except that > > it doesn't call hidms_input, but implements that itself? > > I believe that a new driver makes more sense. Because if one wants to > extend your work to fully support the drawing table it won't be able to > do it in ums(4). That's what I thought after building the current patch, thanks for confirming this. > I afraid you'll need to match the two interfaces of your device, > something which is not trivial with the current framework. Do you know of a driver that currently does this? > Newer versions of libinput include some support for various Intuos > devices, you might want to look at this if you haven't done it already. Thanks for the hint, didn't know. I'll dig into this. Frank
Fix Wacom Intuos S 2 descriptor and make wsmouse work
I recently acquired a new Wacom drawing tablet: an Intuos Draw, which
seems to be called an Intuos S 2 internally. I couldn't get this tablet
to work in OpenBSD. One of the HID descriptors describes a mouse, so
ums(4) attaches to it, but no data is ever registered. After digging
around in the Linux driver, it appears that the actual data is reported
in a different descriptor, one that is (possibly on purpose) incorrect.
After writing a correct device descriptor I had to work around two other
problems:
- X & Y data is reported in big endian format.
- Mouse button 1 data is flakey, the linux driver uses pressure to work
around this.
To get the tablet to function correctly, I chose to implement quirks for
this in hidms(4). Attached patch makes the tablet function with mouse
movement and all three stylus events (tip touch and 2 buttons) without
any needed configuration. This is enough functionality for for me, I
just use it as a mouse replacement to avoid getting RSI.
Example dmesg output on attachment:
uhidev0 at uhub3 port 2 configuration 1 interface 0 "Wacom Co.,Ltd.
Intuos PS" rev 2.00/1.00 addr 3
uhidev0: iclass 3/0, 192 report ids
ums0 at uhidev0 reportid 16: 3 buttons
wsmouse1 at ums0 mux 0
uhid0 at uhidev0 reportid 192: input=4, output=0, feature=0
uhidev1 at uhub3 port 2 configuration 1 interface 1 "Wacom Co.,Ltd.
Intuos PS" rev 2.00/1.00 addr 3
uhidev1: iclass 3/0, 3 report ids
uhid1 at uhidev1 reportid 2: input=63, output=0, feature=0
uhid2 at uhidev1 reportid 3: input=63, output=0, feature=0
uhidev2 at uhub3 port 2 configuration 1 interface 2 "Wacom Co.,Ltd.
Intuos PS" rev 2.00/1.00 addr 3
uhidev2: iclass 3/1, 1 report id
ums1 at uhidev2 reportid 1: 5 buttons
wsmouse2 at ums1 mux 0
The first tattached umse is the functioning one that is added by this
patch.
Is the attached patch acceptable? Or would it be better to write a
seperate driver, such as uwacom, that does the same as ums, except that
it doesn't call hidms_input, but implements that itself?
Frank
Index: hid/hidms.c
===
RCS file: /cvs/src/sys/dev/hid/hidms.c,v
retrieving revision 1.3
diff -u -p -r1.3 hidms.c
--- hid/hidms.c 22 May 2016 22:06:11 - 1.3
+++ hid/hidms.c 2 Aug 2016 19:15:09 -
@@ -109,6 +109,9 @@ hidms_setup(struct device *self, struct
return ENXIO;
}
+ hid_locate(desc, dlen, HID_USAGE2(HUP_DIGITIZERS, HUD_TIP_PRESSURE),
+ id, hid_input, >sc_loc_tip_press, );
+
/*
* Try to guess the Z activator: check WHEEL, TWHEEL, and Z,
* in that order.
@@ -368,6 +371,11 @@ hidms_input(struct hidms *ms, uint8_t *d
dz = -dz;
if (ms->sc_flags & HIDMS_REVW)
dw = -dw;
+ if (ms->sc_flags & HIDMS_BE16_X)
+ dx = be16toh(dx);
+ if (ms->sc_flags & HIDMS_BE16_Y)
+ dy = be16toh(dy);
+
if (ms->sc_tsscale.swapxy && !ms->sc_rawmode) {
int tmp = dx;
@@ -388,6 +396,13 @@ hidms_input(struct hidms *ms, uint8_t *d
for (i = 0; i < ms->sc_num_buttons; i++)
if (hid_get_data(data, len, >sc_loc_btn[i]))
buttons |= (1 << HIDMS_BUT(i));
+
+ if (ms->sc_flags & HIDMS_USE_TIP_PRESS) {
+ if (hid_get_data(data, len, >sc_loc_tip_press) > 10)
+ buttons |= (1 << HIDMS_BUT(0));
+ else
+ buttons &= ~(1 << HIDMS_BUT(0));
+ }
if (dx != 0 || dy != 0 || dz != 0 || dw != 0 ||
buttons != ms->sc_buttons) {
Index: hid/hidmsvar.h
===
RCS file: /cvs/src/sys/dev/hid/hidmsvar.h,v
retrieving revision 1.1
diff -u -p -r1.1 hidmsvar.h
--- hid/hidmsvar.h 8 Jan 2016 15:54:13 - 1.1
+++ hid/hidmsvar.h 2 Aug 2016 19:15:09 -
@@ -43,18 +43,21 @@ struct tsscale {
struct hidms {
int sc_enabled;
int sc_flags; /* device configuration */
-#define HIDMS_SPUR_BUT_UP 0x001 /* spurious button up events */
-#define HIDMS_Z0x002 /* Z direction available */
-#define HIDMS_REVZ 0x004 /* Z-axis is reversed */
-#define HIDMS_W0x008 /* W direction available */
-#define HIDMS_REVW 0x010 /* W-axis is reversed */
-#define HIDMS_LEADINGBYTE 0x020 /* Unknown leading byte */
-#define HIDMS_ABSX 0x040 /* X-axis is absolute */
-#define HIDMS_ABSY 0x080 /* Y-axis is absolute */
-#define HIDMS_TIP 0x100 /* Tip switch on a digitiser pen */
-#define HIDMS_BARREL 0x200 /* Barrel switch on a digitiser pen */
-#define HIDMS_ERASER 0x400 /* Eraser switch on a digitiser pen */
-#define HIDMS_MS_BAD_CLASS 0x800 /* Mouse doesn't identify properly */
+#define HIDMS_SPUR_BUT_UP 0x0001 /* spurious button up events */
+#define
Re: Add hotkey support for Asus Zenbook UX31A
On Thu, Jul 14, 2016 at 08:41:42PM +0200, Frank Groeneveld wrote:
> Thanks for reviewing. This the only ACPI device that works when
> attaching (volume buttons start working). I've added the dumps
> below.
Attached updated patch also adds the ws_get_param and ws_set_param
methods to prevent acpivideo from attaching. This makes the backlight
control work (altough not with hotkeys, only audio keys seem to work).
Frank
Index: dev/acpi/acpiasus.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiasus.c,v
retrieving revision 1.17
diff -u -p -r1.17 acpiasus.c
--- dev/acpi/acpiasus.c 21 Feb 2014 18:49:06 - 1.17
+++ dev/acpi/acpiasus.c 16 Jul 2016 14:05:43 -
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include "audio.h"
#include "wskbd.h"
@@ -81,6 +82,10 @@ void acpiasus_attach(struct device *, st
void acpiasus_init(struct device *);
intacpiasus_notify(struct aml_node *, int, void *);
intacpiasus_activate(struct device *, int);
+intacpiasus_get_param(struct wsdisplay_param *);
+intacpiasus_set_param(struct wsdisplay_param *);
+extern int (*ws_get_param)(struct wsdisplay_param *);
+extern int (*ws_set_param)(struct wsdisplay_param *);
#if NAUDIO > 0 && NWSKBD > 0
extern int wskbd_set_mixervolume(long, long);
@@ -95,7 +100,7 @@ struct cfdriver acpiasus_cd = {
NULL, "acpiasus", DV_DULL
};
-const char *acpiasus_hids[] = { ACPI_DEV_ASUS, 0 };
+const char *acpiasus_hids[] = { ACPI_DEV_ASUS, ACPI_DEV_ASUS2, 0 };
int
acpiasus_match(struct device *parent, void *match, void *aux)
@@ -119,6 +124,9 @@ acpiasus_attach(struct device *parent, s
acpiasus_init(self);
+ ws_get_param = acpiasus_get_param;
+ ws_set_param = acpiasus_set_param;
+
aml_register_notify(sc->sc_devnode, aa->aaa_dev,
acpiasus_notify, sc, ACPIDEV_NOPOLL);
}
@@ -225,4 +233,16 @@ acpiasus_activate(struct device *self, i
break;
}
return (0);
+}
+
+int
+acpiasus_get_param(struct wsdisplay_param *dp)
+{
+ return -1;
+}
+
+int
+acpiasus_set_param(struct wsdisplay_param *dp)
+{
+ return -1;
}
Index: dev/acpi/acpireg.h
===
RCS file: /cvs/src/sys/dev/acpi/acpireg.h,v
retrieving revision 1.36
diff -u -p -r1.36 acpireg.h
--- dev/acpi/acpireg.h 10 Jul 2016 20:36:41 - 1.36
+++ dev/acpi/acpireg.h 16 Jul 2016 14:05:43 -
@@ -764,6 +764,7 @@ struct acpi_ivrs {
#define ACPI_DEV_FFB "FIXEDBUTTON" /* Fixed Feature Button */
#define ACPI_DEV_ASUS "ASUS010" /* ASUS Hotkeys */
#define ACPI_DEV_ASUS1 "ATK0100" /* ASUS Special Device */
+#define ACPI_DEV_ASUS2 "pnp0c14" /* ASUS Zenbook UX31A Hotkeys */
#define ACPI_DEV_IBM "IBM0068" /* IBM ThinkPad support */
#define ACPI_DEV_LENOVO"LEN0068" /* Lenovo ThinkPad support */
#define ACPI_DEV_ASUSAIBOOSTER "ATK0110" /* ASUSTeK AI Booster */
Re: Add hotkey support for Asus Zenbook UX31A
On Thu, Jul 14, 2016 at 07:42:28PM +0200, Mark Kettenis wrote:
> Please send the acpidump output for that machine; "pnp0c14" for an
> ASUS-specific device looks wrong.
Thanks for reviewing. This the only ACPI device that works when
attaching (volume buttons start working). I've added the dumps
below.
Frank
zenbook_ux31a.APIC.3
Description: Binary data
zenbook_ux31a.BGRT.17
Description: Binary data
zenbook_ux31a.DMAR.16
Description: Binary data
zenbook_ux31a.DSDT.2
Description: Binary data
zenbook_ux31a.ECDT.5
Description: Binary data
zenbook_ux31a.FACP.1
Description: Binary data
zenbook_ux31a.FPDT.4
Description: Binary data
zenbook_ux31a.HPET.11
Description: Binary data
zenbook_ux31a.MCFG.6
Description: Binary data
zenbook_ux31a.SSDT.10
Description: Binary data
zenbook_ux31a.SSDT.12
Description: Binary data
zenbook_ux31a.SSDT.13
Description: Binary data
zenbook_ux31a.SSDT.14
Description: Binary data
zenbook_ux31a.SSDT.14
Description: Binary data
zenbook_ux31a.SSDT.15
Description: Binary data
zenbook_ux31a.SSDT.7
Description: Binary data
zenbook_ux31a.SSDT.8
Description: Binary data
zenbook_ux31a.SSDT.9
Description: Binary data
RSD PTR: Checksum=106, OEMID=_ASUS_, RsdtAddress=0xda89f028
RSDT: Length=104, Revision=1, Checksum=177,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x1072009,
Creator ID=MSFT, Creator Revision=0x10013
Entries={ 0xda89f148, 0xda8b13d0, 0xda8b1448, 0xda8b1490, 0xda8b1558,
0xda8b1598, 0xda8b1fd8, 0xda8b2c80, 0xda8b2d18, 0xda8b3638, 0xda8b3670,
0xda8b3ad0, 0xda8b3f70, 0xda8b4940, 0xda8b5458, 0xda8b5508, 0xda64ce18 }
DSDT=0xda89f1d0
INT_MODEL=APIC
SCI_INT=9
SMI_CMD=0xb2, ACPI_ENABLE=0xb0, ACPI_DISABLE=0xb1, S4BIOS_REQ=0x0
PM1a_EVT_BLK=0x400-0x403
PM1a_CNT_BLK=0x404-0x405
PM2_CNT_BLK=0x450-0x450
PM2_TMR_BLK=0x408-0x40b
PM2_GPE0_BLK=0x420-0x42f
P_LVL2_LAT=101ms, P_LVL3_LAT=57ms
FLUSH_SIZE=1024, FLUSH_STRIDE=16
DUTY_OFFSET=0, DUTY_WIDTH=0
DAY_ALRM=13, MON_ALRM=0, CENTURY=50
Flags={WBINVD,PROC_C1,PWR_BUTTON,SLP_BUTTON,RTC_S4,DCK_CAP}
DSDT: Length=73964, Revision=2, Checksum=176,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x13,
Creator ID=INTL, Creator Revision=0x20091112
APIC: Length=114, Revision=3, Checksum=207,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x1072009,
Creator ID=AMI, Creator Revision=0x10013
FPDT: Length=68, Revision=1, Checksum=41,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x1072009,
Creator ID=AMI, Creator Revision=0x10013
ECDT: Length=193, Revision=1, Checksum=246,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x1072009,
Creator ID=AMI., Creator Revision=0x5
MCFG: Length=60, Revision=1, Checksum=50,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x1072009,
Creator ID=MSFT, Creator Revision=0x97
SSDT: Length=2620, Revision=1, Checksum=131,
OEMID=DptfTa, OEM Table ID=DptfTab, OEM Revision=0x1000,
Creator ID=INTL, Creator Revision=0x20091112
SSDT: Length=3237, Revision=1, Checksum=213,
OEMID=SADptf, OEM Table ID=SADptf_, OEM Revision=0x1000,
Creator ID=INTL, Creator Revision=0x20091112
SSDT: Length=152, Revision=1, Checksum=179,
OEMID=PchDpt, OEM Table ID=PchDptf, OEM Revision=0x1000,
Creator ID=INTL, Creator Revision=0x20091112
SSDT: Length=2332, Revision=1, Checksum=238,
OEMID=CfgTDP, OEM Table ID=CfgTDP_, OEM Revision=0x1000,
Creator ID=INTL, Creator Revision=0x20091112
HPET: Length=56, Revision=1, Checksum=63,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x1072009,
Creator ID=AMI., Creator Revision=0x5
SSDT: Length=1118, Revision=1, Checksum=194,
OEMID=AhciR1, OEM Table ID=AhciTab1, OEM Revision=0x1000,
Creator ID=INTL, Creator Revision=0x20091112
SSDT: Length=1182, Revision=1, Checksum=231,
OEMID=AhciR2, OEM Table ID=AhciTab2, OEM Revision=0x1000,
Creator ID=INTL, Creator Revision=0x20091112
SSDT: Length=2512, Revision=1, Checksum=95,
OEMID=PmRef, OEM Table ID=Cpu0Ist, OEM Revision=0x3000,
Creator ID=INTL, Creator Revision=0x20051117
SSDT: Length=2840, Revision=1, Checksum=147,
OEMID=PmRef, OEM Table ID=CpuPm, OEM Revision=0x3000,
Creator ID=INTL, Creator Revision=0x20051117
DMAR: Length=176, Revision=1, Checksum=82,
OEMID=INTEL, OEM Table ID=SNB, OEM Revision=0x1,
Creator ID=INTL, Creator Revision=0x1
BGRT: Length=56, Revision=0, Checksum=106,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x1072009,
Creator ID=ASUS, Creator Revision=0x10013
MSDM: Length=85, Revision=3, Checksum=131,
OEMID=_ASUS_, OEM Table ID=Notebook, OEM Revision=0x0,
Creator ID=ASUS, Creator Revision=0x1
zenbook_ux31a.MSDM.18
Description: Binary data
Add hotkey support for Asus Zenbook UX31A
Attached patch adds hotkey support for the Zenbook UX31A. I wasn't sure
what to name the magic string, so please rename to whatever you find
more suitable.
Next step in getting the Zenbook UX31A to work better is finding a neat
way to prevent acpivideo from attaching. After the recent refactoring it
seems I need to define ws_get_param and ws_set_param in acpiasus to do
that, right?
Frank
Index: dev/acpi/acpiasus.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiasus.c,v
retrieving revision 1.17
diff -u -p -r1.17 acpiasus.c
--- dev/acpi/acpiasus.c 21 Feb 2014 18:49:06 - 1.17
+++ dev/acpi/acpiasus.c 14 Jul 2016 17:10:20 -
@@ -95,7 +95,7 @@ struct cfdriver acpiasus_cd = {
NULL, "acpiasus", DV_DULL
};
-const char *acpiasus_hids[] = { ACPI_DEV_ASUS, 0 };
+const char *acpiasus_hids[] = { ACPI_DEV_ASUS, ACPI_DEV_ASUS2, 0 };
int
acpiasus_match(struct device *parent, void *match, void *aux)
Index: dev/acpi/acpireg.h
===
RCS file: /cvs/src/sys/dev/acpi/acpireg.h,v
retrieving revision 1.36
diff -u -p -r1.36 acpireg.h
--- dev/acpi/acpireg.h 10 Jul 2016 20:36:41 - 1.36
+++ dev/acpi/acpireg.h 14 Jul 2016 17:10:20 -
@@ -764,6 +764,7 @@ struct acpi_ivrs {
#define ACPI_DEV_FFB "FIXEDBUTTON" /* Fixed Feature Button */
#define ACPI_DEV_ASUS "ASUS010" /* ASUS Hotkeys */
#define ACPI_DEV_ASUS1 "ATK0100" /* ASUS Special Device */
+#define ACPI_DEV_ASUS2 "pnp0c14" /* ASUS Zenbook UX31A Hotkeys */
#define ACPI_DEV_IBM "IBM0068" /* IBM ThinkPad support */
#define ACPI_DEV_LENOVO"LEN0068" /* Lenovo ThinkPad support */
#define ACPI_DEV_ASUSAIBOOSTER "ATK0110" /* ASUSTeK AI Booster */
Re: initial 11n support for iwn (n, not m)
On 12/19/15 13:08, Stefan Sperling wrote: On Fri, Dec 18, 2015 at 05:40:39PM -0500, David Hill wrote: Here's an updated iwn diff with a better approach for Stuart's fix. Thanks for helping, Stuart, and to everyone who sent beacons which allowed us to narrow this problem down to protection settings being set up the wrong way in iwn_run(). Assuming this fix was in yesterdays snapshot, it fixes my previously reported association problems. Thank you! Frank
Re: initial 11n support for iwn (n, not m)
On 12/16/15 15:35, Stefan Sperling wrote: This diff adds 11n MCS 0-7 with A-MPDU and A-MSDU Rx to the iwn(4) driver. It also tweaks replay detection for CCMP encrypted frames, which needed tweaking for A-MPDU anyway (see comments in code). Even in non-11n modes this driver was discarding some retransmitted frames for no good reason. This driver supports a very wide range of hardware so please test this with as many iwn(4) adapters as possible. If we don't get enough tests this change may not be able to make the 5.9 release. Works for me on: iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, MIMO 2T2R, MoW Please post here or let me know in private which hardware you're testing on. Thanks. Note that if you'd like to test monitor mode you'll need to apply this to a -current source tree from today. Thanks for you work on this! I've tested it on my laptop and it gives me firmware errors. I've attached dmesg from both a the working and the patched, non-working kernels. Let me know if you need any other information. Frank OpenBSD 5.8-current (GENERIC.MP) #1737: Thu Dec 10 23:29:07 MST 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4157837312 (3965MB) avail mem = 4027703296 (3841MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeba60 (23 entries) bios0: vendor American Megatrends Inc. version "UX31A.219" date 06/14/2013 bios0: ASUSTeK COMPUTER INC. UX31A acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT ECDT MCFG SSDT SSDT SSDT SSDT HPET SSDT SSDT SSDT SSDT DMAR MSDM acpi0: wakeup devices P0P1(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) EHC2(S3) USB5(S3) USB6(S3) USB7(S3) HDEF(S4) RP01(S4) RP02(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz, 1796.22 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz, 1795.92 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz, 1795.92 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz, 1795.92 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,OSXSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpiec0 at acpi0 acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus -1 (PEG0) acpiprt3 at acpi0: bus -1 (PEG1) acpiprt4 at acpi0: bus -1 (PEG2) acpiprt5 at acpi0: bus -1 (PEG3) acpiprt6 at acpi0: bus 1 (RP01) acpiprt7 at acpi0: bus 2 (RP02) acpiprt8 at acpi0: bus -1 (RP03) acpiprt9 at acpi0: bus -1 (RP04) acpiprt10 at acpi0: bus -1 (RP05) acpiprt11 at acpi0: bus -1 (RP06) acpiprt12 at acpi0: bus -1 (RP07) acpiprt13 at acpi0: bus -1 (RP08) acpicpu0 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@87 mwait.1@0x30), C2(500@59 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@87
[PATCH] typo in vmm.conf(5)
I've been testing vmm(8) and it seems to work great so far. Keep up the good work! I found a small typo in one of the man pages. A diff to fix it below. Frank Index: usr.sbin/vmmctl/vmm.conf.5 === RCS file: /cvs/src/usr.sbin/vmmctl/vmm.conf.5,v retrieving revision 1.4 diff -u -p -r1.4 vmm.conf.5 --- usr.sbin/vmmctl/vmm.conf.5 23 Nov 2015 13:40:28 - 1.4 +++ usr.sbin/vmmctl/vmm.conf.5 23 Nov 2015 20:09:03 - @@ -44,7 +44,7 @@ subsystem. Configuration for each individual virtual machine. .El .Pp -Withint the sections, +Within the sections, the current line can be extended over multiple lines using a backslash .Pq Sq \e . Comments can be put anywhere in the file using a hash mark
