Re: hidmt: default to clickpad unless report says otherwise

On Fri, 20 May 2022 at 16:46:01 +0200, Ulf Brosziewski wrote: > Shouldn't the check of the button page remain in place, for identifying > plain old touchpads with external buttons? The device in question reports it has multiple buttons when it's just a clickpad, so keeping that check would

hidmt: default to clickpad unless report says otherwise

Most Windows Precision Touchpad-style touchpads will be clickpads, with no-button "pressure pad" style devices being the outlier. Make clickpad the default unless the report says otherwise. This fixes the Framework laptop which has a PixArt touchpad with a weird HID descriptor report which

DPTF sensors driver

temp0=29.05 degC (Thermistor USB Type-C) commit 959656ab8227367705adc45d73f5b6d47d552ac3 Author: joshua stein Date: Mon Aug 9 12:45:15 2021 -0500 acpidptfs: Add a driver for Dynamic Platform and Thermal Framework sensors diff --git sys/arch/amd64/conf/GENERIC sys/arch/amd64/conf/GENERIC index

xenodm and login_fbtab

xenodm supports login_fbtab(3) to chown devices but it currently doesn't do anything because /etc/fbtab does not list /dev/ttyC4. It uses the GiveConsole and TakeConsole scripts in /etc/X11/xenodm/ to do this manually, but the file lists are not complete. I would like to remove all of the

Re: login_fbtab glob

On Fri, 15 Apr 2022 at 18:54:49 -0600, Todd C. Miller wrote: > On Fri, 15 Apr 2022 13:28:33 -0500, joshua stein wrote: > > > Anyone want to bikeshed this language? > > I think it is more helpful to refer to glob(7) than glob(3). > Perhaps something like this. I like it.

Re: login_fbtab glob

On Fri, 15 Apr 2022 at 12:17:12 -0600, Todd C. Miller wrote: > On Fri, 15 Apr 2022 13:12:03 -0500, joshua stein wrote: > > > Thanks, both applied. > > Looks good to me but needs a man page update. Anyone want to bikeshed this language? diff --git share/man/man5/fbtab.5 shar

Re: login_fbtab glob

On Fri, 15 Apr 2022 at 09:32:46 -0600, Todd C. Miller wrote: > On Thu, 14 Apr 2022 17:52:37 -0500, joshua stein wrote: > > > login_fbtab(3) supports wildcards but only for every file in a > > directory (/path/*). > > > > This makes it use glob(3) so it

login_fbtab glob

login_fbtab(3) supports wildcards but only for every file in a directory (/path/*). This makes it use glob(3) so it can also support more specific wildcards like /path/file* diff --git lib/libutil/login_fbtab.c lib/libutil/login_fbtab.c index 5eacf4f65ff..39621a0cde4 100644 ---

Re: sndiod: -F does not switch back to preferred device

1,5 +1,6 @@ /* $OpenBSD: hotplug.c,v 1.16 2016/06/07 01:31:54 tedu Exp $ */ /* + * Copyright (c) 2018 joshua stein * Copyright (c) 2004 Alexander Yurchenko * * Permission to use, copy, modify, and distribute this software for any @@ -25,15 +26,24 @@ #include #include #include

Re: iwx(4) 40MHz channel support

On Thu, 14 Oct 2021 at 09:21:18 +0200, Stefan Hagen wrote: > This ramp up time is reproducible. It always starts slower in the first > 1 or 2 seconds and then ramps up to full speed. I've observed this in ethernet transfers on OpenBSD for a long time, it's not limited to WiFi.

Re: ihidev: fix data request size

On Sun, 22 Aug 2021 at 22:37:51 -0600, Thomas Frohwein wrote: > On Sun, Aug 22, 2021 at 09:50:15PM -0500, joshua stein wrote: > > On a particular laptop with a touchpad behind ihidev, dwiic would > > report a timeout every time it had to fetch touch data: > > > >

ihidev: fix data request size

On a particular laptop with a touchpad behind ihidev, dwiic would report a timeout every time it had to fetch touch data: dwiic0: timed out reading remaining 2 On re-reading the i2c HID spec, the size supplied by wMaxInputLength is already supposed to account for the size and report id

Re: ucc(4): consumer control keyboard device driver

On Wed, 18 Aug 2021 at 18:48:45 +0200, Martin Pieuchot wrote: > Regarding the introduction of a separate wskbd(4) this can be seen as an > intermediate step. Having this logic in ukbd(4) implies revisiting the > way reportID are mapped to USB drivers, which is still a bit of a hack > when it

Re: usbhidctl: add -R flag to dump raw report descriptor bytes

On Fri, 28 May 2021 at 21:52:57 -0500, joshua stein wrote: > > Another approach which keeps the structure opaque is the extend the > > usbhid(3) API with something like: > > > > void > > hid_get_report_desc_data(report_desc_t d, uint8

Re: usbhidctl: add -R flag to dump raw report descriptor bytes

On Wed, 26 May 2021 at 08:13:52 +0200, Anton Lindqvist wrote: > On Tue, May 25, 2021 at 08:31:14AM +0200, Anton Lindqvist wrote: > > On Mon, May 24, 2021 at 09:17:26AM -0500, joshua stein wrote: > > > This is useful for parsing the report descriptor with a different > &g

usbhidctl: add -R flag to dump raw report descriptor bytes

This is useful for parsing the report descriptor with a different tool to find issues with our HID parser. I've found https://eleccelerator.com/usbdescreqparser/ to be helpful. diff --git usr.bin/usbhidctl/usbhid.c usr.bin/usbhidctl/usbhid.c index 921f211a280..bd0b5da0222 100644 ---

hidms: don't ignore mice with no x/y coordinates

A bug was reported where a Kensington USB trackball didn't work properly: uhidev4 at uhub0 port 6 configuration 1 interface 0 "Kensington Expert Wireless TB" rev 2.00/1.02 addr 9 uhidev4: iclass 3/1, 3 report ids ums3 at uhidev4 reportid 1 ums3: mouse has no X report ums4 at

Re: [Diff] Implement multiple device cloning for hotplug

On Tue, 11 May 2021 at 22:37:55 -0400, Ashton Fagg wrote: > Inspiration for this diff was drawn from Joshua Stein [1], seeminly he > had a use-case that was somewhat similar to mine at one point but it > doesn't look like this was ever committed. Nor can I find any discussion > on it.

Re: virtio(4) at fdt: version 2 for Parallels 16 on Mac (M1)

On Wed, 14 Apr 2021 at 22:55:14 +0200, Mark Kettenis wrote: > > cpu0 at mainbus0 mpidr 0: Unknown, MIDR 0x410f > > That's a strange ARM CPU ;). > > If you have some time, can you run a make -j in /usr/src/lib/libc? > I'm curious if cc or ld crashes in a virtual machine. I just built all of

xf86-input-ws: fix hotplugging usb mice on legacy-free machines

The X server's autoconfiguration probes each /dev/wsmouseN device and if its WSMOUSEIO_GTYPE ioctl returns something like WSMOUSE_TYPE_TOUCHPAD, xf86-input-ws attaches to that device directly which causes the wsmouse device to detach from the mux. This allows xinput to handle these special

uhidev: allow devices to match specific multiple reports

uhidev allows a child device to claim all reports by calling *_match functions with the report id set to UHIDEV_CLAIM_ALLREPORTID. umt needs this because it has to access 3 reports which has worked okay up until now because devices with umt and a ukbd have usually presented them on separate

ddb: resize when new console attaches

This way we aren't wrapping ddb output lines halfway across the screen on a modern console. diff --git sys/ddb/db_output.c sys/ddb/db_output.c index 77fd0e34944..72b9a24e761 100644 --- sys/ddb/db_output.c +++ sys/ddb/db_output.c @@ -252,3 +252,10 @@ stacktrace_print(struct stacktrace *st, int

ims: claim to be a touchpad

There are no i2c-connected mice and ims(4) will always be a touchpad/touchscreen/stylus that just doesn't meet the requirements of imt(4). Presenting it as WSMOUSE_TYPE_TOUCHPAD makes the X server set it up as a separate pointer which may be useful. Index: sys/dev/i2c/ims.c

Re: tpm(4): removing tvtohz(9)?

On Fri, 18 Dec 2020 at 18:58:43 -0600, Scott Cheloha wrote: > Hi, > > tpm(4) is the last driver in the tree using tvtohz(9). There are no > remaining callers using tstohz(9), so if and when we remove tvtohz(9) > from tpm(4) we can remove both interfaces from the tree. > > tpm(4) is tricky

Re: acpiapplesmc(4)

On Mon, 07 Sep 2020 at 06:58:01 +0200, Marcus Glocker wrote: > This is an initial driver for the Apple System Management Controller > found in Intel based Apple computers. > > The driver is currently missing support for the Sudden Motion Sensor > (SMS), light sensor, and keyboard backlight since

exar XR17V35x (again)

In 2018 I added support for Exar XR17V35x serial ports: The Exar XR17V354 has 4 com ports that have a 256-byte FIFO, use a frequency of 125Mhz, and have a unique sleep register. A custom interrupt handler is setup in puc for these ports so it can check a register which reports

imt/hidmt: work better with dual touchpad/trackstick devices

.c @@ -3,7 +3,7 @@ * HID-over-i2c multitouch trackpad driver for devices conforming to * Windows Precision Touchpad standard * - * https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314%28v=vs.85%29.aspx + * https://docs.microsoft.com/en-us/windows-hardware/design/component-gui

Re: Give support to the 2019 Apple's MBP (13-inch)

On Thu, 11 Jun 2020 at 08:29:12 +0200, Romero Pérez, Abel wrote: > Hello, > > I tried to install stable flavor from USB on the MBP 13-inch 2019, with no > luck, and the following issues: > > 1. Booting kernel messages > > Centered on the screen, with a very small size, not working well for >

Re: acpihid: INT33D5 driver

/man/man4/acpihid.4 new file mode 100644 index 000..d9914cec7b7 --- /dev/null +++ share/man/man4/acpihid.4 @@ -0,0 +1,42 @@ +.\"$OpenBSD$ +.\" +.\" Copyright (c) 2020 joshua stein +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\

umstc: Microsoft Surface Type Cover driver

file mode 100644 index 000..da557c59d1d --- /dev/null +++ share/man/man4/umstc.4 @@ -0,0 +1,44 @@ +.\"$OpenBSD$ +.\" +.\" Copyright (c) 2020 joshua stein +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or

acpihid: INT33D5 driver

\ acpitimer.4 acpivideo.4 acpivout.4 acpitz.4 \ diff --git share/man/man4/acpihid.4 share/man/man4/acpihid.4 new file mode 100644 index 000..8d54da962d1 --- /dev/null +++ share/man/man4/acpihid.4 @@ -0,0 +1,47 @@ +.\"$OpenBSD$ +.\" +.\" Copyright (c) 20

Re: Mouse movement speed

On Sun, 17 May 2020 at 16:17:46 -0700, jo...@armadilloaerospace.com wrote: > I enabled wsmoused for console mouse support, but the cursor was > unusably fast. This is a high resolution, high update rate USB gaming > mouse, but it was off by well over an order of magnitude. > > I searched for a

Re: posix_openpt: allow O_CLOEXEC

On Thu, 06 Feb 2020 at 12:41:47 -0700, Theo de Raadt wrote: > > Index: stdlib/posix_pty.c > > === > > RCS file: /cvs/src/lib/libc/stdlib/posix_pty.c,v > > retrieving revision 1.3 > > diff -u -p -u -p -r1.3 posix_pty.c > > ---

Re: posix_openpt: allow O_CLOEXEC

On Thu, 06 Feb 2020 at 11:21:11 -0700, Todd C. Miller wrote: > On Thu, 06 Feb 2020 10:45:44 -0700, "Theo de Raadt" wrote: > > > That feels better, and will be more atomic. > > Unfortunately, we can't do this in ptmioctl() since we don't have > the index of the open ptm device to use to check for

Re: posix_openpt: allow O_CLOEXEC

On Wed, 05 Feb 2020 at 17:48:41 -0700, Todd C. Miller wrote: > On Wed, 05 Feb 2020 15:47:37 -0600, joshua stein wrote: > > > The spec says the behavior of anything other than O_RDWR and > > O_NOCTTY is unspecified, but FreeBSD allows passing O_CLOEXEC. > > OK, but the

posix_openpt: allow O_CLOEXEC

The spec says the behavior of anything other than O_RDWR and O_NOCTTY is unspecified, but FreeBSD allows passing O_CLOEXEC. Index: lib/libc/stdlib/posix_openpt.3 === RCS file: /cvs/src/lib/libc/stdlib/posix_openpt.3,v retrieving

Re: iwm(4): support for MSI-X

On Wed, 20 Nov 2019 at 14:59:41 +0100, Patrick Wildt wrote: > Hi, > > on my Intel NUC 8i5BEHs that has a 9560 chip the current in-tree > support for the 9000 series does not work. The issue seems to be > the interrupt delivery. The first interrupt we wait for, which is > loading the firmware

Re: iwm: support 9260 devices

On Sat, 16 Nov 2019 at 19:08:05 +0100, Stefan Sperling wrote: > On Sat, Nov 16, 2019 at 11:44:03AM -0600, joshua stein wrote: > > Awesome, thanks guys. It's working great on the 9560 on my ThinkPad > > X1C7. A speed test showed 44/18 Mbps and it continues to work fine > &

Re: iwm: support 9260 devices

On Sat, 16 Nov 2019 at 17:09:40 +0100, Stefan Sperling wrote: > On Sat, Nov 16, 2019 at 04:51:44PM +0100, Stefan Sperling wrote: > > This diff adds support for iwm(4) 9260 devices and hopefully 9560 > > devices as well but I have not yet had time to test those. > > > > Joint work with patrick@.

acpithinkpad: don't take over ws_[gs]et_param on version 2 devices

Newer ThinkPads have ACPI goo to allow acpivout to control screen backlight, so don't take over ws_[gs]et_param from it. This allows for 100 levels of backlight control rather than the 10 or 15 that are supported through acpithinkpad using its proprietary ACPI or CMOS interfaces. You can see

acpivout: try to consistently adjust brightness by 5%

When responding to hardware keys to increment or decrement screen brightness, don't just adjust by 1 BCL level as there may be 100 levels. Find the next brightness level that is at least 5% up or down, and use that. Index: dev/acpi/acpivout.c

Re: apmd battery emergency message

On Fri, 20 Sep 2019 at 17:00:39 +0200, Alexander Bluhm wrote: > Hi, > > sometimes my laptop was running out of battery while I was working. > To avoid that, I patched apmd(8) to write a emergency message to > syslog(3). Then with this line in syslog.conf I receive a warning > in every xterm. >

azalia: quirk for thinkpad x1c7

The ThinkPad X1 Carbon 7th generation has 4 speakers now, but the default setup connects both speaker and speaker2 to the same DAC. The speaker2 set needs to be routed to a different DAC (dac-0:1) to work properly. This also adds the 300 Series HDA controller to the list of devices where

ihidev: always register interrupt, stop polling if it fires

The fast polling of ihidev may cause a problem during suspend/resume because dwiic may be in an unknown state, so add a DVACT_QUIESCE handler to properly shut it down. Even if polling is requested, register the interrupt handler too. If it ever fires, stop polling and just use the interrupt.

Re: [Patch] Driver for Keyspan USA-19HS

On Mon, 03 Jun 2019 at 23:44:37 -0400, Cody Cutler wrote: > Hi jcs and tech, the following is a patch which implements jcs's feedback and > adds a man page. Thanks Cody, I've imported your driver.

Re: [Patch] Driver for Keyspan USA-19HS

Hi, Some feedback inline: On Tue, 28 May 2019 at 18:42:51 -0400, Cody Cutler wrote: > Hello tech, I'm submitting the following patch for inclusion. The patch > implements a driver for the Keyspan USA-19HS USB-to-serial dongle. > > I've used it for a few months now without any problems. Please

ubcmtp: fix multi-finger on type4 devices

A previous version of this last year broke on some devices because it tried to pass in pressure data. This version only fixes the padding data of type4 devices. Tested on the 2015 MacBook Pro. Tests on other Apple devices would be appreciated. Index: sys/dev/usb/ubcmtp.c

ihidev: fix possible panic

psize is built from the first two bytes read from the device, but it could be completely bogus, especially when polling. This can result in a panic when reading p. Promote it to a signed int to catch it going negative and discard it if it's 2 or less, because shortly after it is decreased by

Re: wscons: precision scrolling

On Sun, 17 Mar 2019 at 19:35:17 +0100, Ulf Brosziewski wrote: > Hi Joshua, > > could you make a test with the updated diff below and check whether > the scroll speed is normal? (There are no changes in ws, it's just > the kernel part). Hi, this version scrolls much better.

ihidev: always register interrupt

I still haven't figured out why ihidev doesn't receive interrupts for I2C devices on Intel 100 series and newer. But on an Intel 300 series laptop, I noticed that the Elan touchscreen (ims at ihidev) does actually generate interrupts while the Elan touchpad (imt at ihidev) doesn't. In this

Re: wscons: precision scrolling

On Thu, 14 Mar 2019 at 00:48:33 +0100, Ulf Brosziewski wrote: > Much too fast? I'm a bit surprised. In my tests, the new method was > generally somewhat slower than the old one (and I haven't changed the > "scroll units"). How did you test it? Which hardware and which applications > did you

dwiic at pci: fetch timing parameters from acpi

While making dwiic at pci attach on an Intel 300 series laptop, dwiic was timing out while ihidev tried to fetch the HID descriptor. Turns out the default timing parameters pulled from the device are wrong, so try to fetch them from ACPI and use those instead. This matches what dwiic at acpi

Re: wscons: precision scrolling

On Wed, 13 Mar 2019 at 00:41:12 +0100, Ulf Brosziewski wrote: > The standard method of scrolling in X is tailored to mouse wheels and > proceeds in coarse steps. Wheel events are mapped to button events, and on > receiving such an event, an application moves the view of its data by some > fixed

acpithinkpad: a fix for the x260

sthen found that the HKEY version metric failed on the x260 where it reports version 1 but requires the new ACPI method of changing backlight. This diff tries to do the ACPI method on all machines and falls back to the CMOS method if that fails. Can all those that tried the previous diff

acpithinkpad: fix brightness keys, keyboard backlight value

Here we go again... On at least the ThinkPad X1C6, the screen brightness keys (F5 and F6) do not work and "wsconsctl keyboard.backlight" doesn't report the correct value when the keyboard backlight is adjusted with Fn+Space. These are both caused by the default event mask not including these

Re: [PATCH] Add elan(4) touchpad driver

On Fri, 09 Nov 2018 at 03:30:07 +, b...@curlybracket.co.uk wrote: > Hi all, > > This patch adds a new touchpad driver, elan(4), which supports older non > PTP I2C Elantech touchpads. I have tested this on my HP Chromebook 13 > and it appears to work well, multitouch is working as well as the

Re: ims: match on HID touchscreens

On Sat, 01 Sep 2018 at 20:53:45 +0200, Mark Kettenis wrote: > Not sure if that is indeed the right approach, but we can always fix > it in a better way later. The HID report descriptor contains this: [...] 0x05, 0x01,// Usage Page (Generic Desktop Ctrls) 0x09, 0x30,//

ims: match on HID touchscreens

If there is an i2c HID device that has a Digitizers/Touchscreen collection and an X report, attach ims to it. hidms already has support for touchscreens. This may help if you have a newer laptop with a touchscreen. Also limit the logical min/max finding in hidms to the first non-zero result.

umt(4)

- @@ -0,0 +1,47 @@ +.\"$OpenBSD$ +.\" +.\" Copyright (c) 2016-2018 joshua stein +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\&q

fix hid constant conversion

The HID code uses hid_feature, hid_input, and hid_output constants to refer to report types internally that then need to be converted to their bus-level counterparts before actually getting sent out (so hid_feature becomes UHID_FEATURE_REPORT for USB, I2C_HID_REPORT_TYPE_FEATURE for i2c).

ubcmtp: fix multi-finger on type4 devices, pass in proper pressure

Type 4 devices like the MacBookPro12,1 have extra padding in between each chunk of finger data that needs to be skipped, otherwise the offset will be wrong and each additional finger will read as static coordinates. This must have been overlooked when it was added to the driver in 2015 since

stop using WSMOUSE_TYPE_ELANTECH in other drivers (xenocara)

And here is the xenocara part. Index: xserver/config/wscons.c === RCS file: /cvs/xenocara/xserver/config/wscons.c,v retrieving revision 1.21 diff -u -p -u -p -r1.21 wscons.c --- xserver/config/wscons.c 8 Dec 2017 15:02:00 -

stop using WSMOUSE_TYPE_ELANTECH in other drivers

Back when touchpad drivers were using the synaptics Xorg driver, they had to pretend to be Elantech devices in order to get particular packet processing. Since Ulf switched us to wstpad and xf86-input-ws a while ago, these drivers can stop claiming to be WSMOUSE_TYPE_ELANTECH devices and use

Re: inteldrm: always use probed screen size for fb

On Fri, 27 Jul 2018 at 19:44:28 +0200, Mark Kettenis wrote: > > Date: Thu, 26 Jul 2018 17:56:03 -0500 > > From: joshua stein > > > > On Thu, 26 Jul 2018 at 22:26:51 +0200, Mark Kettenis wrote: > > > I'm hesitant to change this code. How does Linux behave on

Re: inteldrm: always use probed screen size for fb

On Thu, 26 Jul 2018 at 22:26:51 +0200, Mark Kettenis wrote: > I'm hesitant to change this code. How does Linux behave on tese > machines? Does it use the invisible part of the framebuffer? Or have > they done away with actually using the kernel framebuffer completely > like some developers

inteldrm: always use probed screen size for fb

On the 2015 MacBook Pro and the 12" MacBook, the firmware reports a framebuffer size of 2880x1800 but the screens are 2560x1600 and 2304x1440. Our console ends up drawing text off screen and the latest few lines can't be read. Once X loads, it probes the outputs again and uses the proper

Re: realpath(3) on a dangling symlink

On Wed, 27 Jun 2018 at 21:35:31 -0500, joshua stein wrote: > symlink("/tmp/link", "/tmp/nonexistent"); Oops, I changed this test code at the last second. The proper test code which incorrectly prints on OpenBSD: resolved realpath of /tmp/nonexistent (returned /

realpath(3) on a dangling symlink

realpath(3) on a symlink that points to a non-existent path returns that path (but also sets errno), rather than returning NULL and setting errno. This is inconsistent with at least Linux, FreeBSD, and macOS. #include #include #include #include #include #include int main() {

rasops: implement scrollback for inteldrm and efifb

Index: arch/amd64/amd64/efifb.c === RCS file: /cvs/src/sys/arch/amd64/amd64/efifb.c,v retrieving revision 1.12 diff -u -p -u -p -r1.12 efifb.c --- arch/amd64/amd64/efifb.c28 Oct 2017 01:48:03 - 1.12 +++

sysctl(8): add -F option to print temps in freedom units

Index: sbin/sysctl/sysctl.8 === RCS file: /cvs/src/sbin/sysctl/sysctl.8,v retrieving revision 1.214 diff -u -p -u -p -r1.214 sysctl.8 --- sbin/sysctl/sysctl.816 Feb 2018 07:27:07 - 1.214 +++ sbin/sysctl/sysctl.8

pckbd: go back to using table 2 by default

In 2007 I changed this code to use table 3 by default, falling back on table 2 (the previous default) or 1. This was done just to make the keyboard on the OQO model 01 work, and these devices are long gone. 10 years later, some newer Lenovo machines seem to have trouble trying this mode

Re: ihidev(4) polling

On Thu, 16 Nov 2017 at 13:42:03 -0500, James Turner wrote: So I have to ask since when I hit you up on icb the above terms where all mentioned. With this diff and what you just committed to src add touchpad support to the Xiaomi Mi Air 12.5"? The Xiaomi Mi Air needs a Sunrise Point GPIO driver

ihidev(4) polling

Now that the dwiic(4) PCI support is in, this implements polling mode for ihidev to work around the problem of ioapic interrupts not arriving for them after setup. I've spent far too much time trying to debug that problem (including much of my time at t2k17), so I made this as a workaround

Re: dwiic: add pci attachment

sys/dev/pci/dwiic_pci.c --- /dev/null 1 Jan 1970 00:00:00 - +++ sys/dev/pci/dwiic_pci.c 10 Nov 2017 15:56:34 - @@ -0,0 +1,204 @@ +/* $OpenBSD$ */ +/* + * Synopsys DesignWare I2C controller + * PCI attachment + * + * Copyright (c) 2015-2017 joshua stein <j...@openbsd.

Re: dwiic: add pci attachment

On Thu, 09 Nov 2017 at 10:14:16 +0100, Remi Locherer wrote: On Fri, Nov 03, 2017 at 12:01:15PM -0500, joshua stein wrote: Intel 100 Series laptops have the DesignWare I2C controller attaching via PCI instead of ACPI, so move the guts of dwiic(4) into ic/ and add dwiic_acpi and dwiic_pci files

Re: inteldrm: reduce i2c busy-wait to 100us

On Wed, 11 Oct 2017 at 11:16:07 +0200, Mark Kettenis wrote: > > Date: Tue, 10 Oct 2017 15:42:26 -0500 > > From: joshua stein <j...@openbsd.org> > > > > On my Kaby Lake laptop, running xbacklight or xrandr causes the > > audio and mouse cursor to pause briefly.

dwiic: add pci attachment

C controller + * PCI attachment + * + * Copyright (c) 2015-2017 joshua stein <j...@openbsd.org> + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission n

inteldrm: reduce i2c busy-wait to 100us

On my Kaby Lake laptop, running xbacklight or xrandr causes the audio and mouse cursor to pause briefly. This is because those codepaths do DRM operations that have to probe all of the available connectors, even disconnected ones. For HDMI, it does i2c operations that have to timeout. Reducing

hidmt: add support for hybrid mode

@@ -4,6 +4,7 @@ * standard * * https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314%28v=vs.85%29.aspx + * https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchscreen-packet-reporting-modes * * Copyright (c) 2016 joshua stein <j...@openbsd.

acpithinkpad fixes for brand new machines

Revision 1.50 of acpithinkpad.c made inteldrm defer to acpithinkpad for screen brightness adjustments instead of handling it natively. That was needed to avoid some synchronization issues on machines where the hardware buttons do the backlight adjustment on their own, and just notify acpithinkpad

acpibat: don't be strict about _BIX being too big

For some reason on at least the ThinkPad X1C 5th Gen, Lenovo makes _BIX return a package with size 21 instead of 20, adding an int at the end after the OEM string value (I'm guessing to be used as an OEM int value). The template that _BIX writes into: Name (BX0I, Package (0x15)

amd64: remove clock warning

Removes this useless error that appears on some modern machines: RTC BIOS diagnostic error ff Index: sys/arch/amd64/isa/clock.c === RCS file:

Re: acpibat: add _BIX support

On Sat, 22 Jul 2017 at 18:07:56 +0200, Mark Kettenis wrote: > > Date: Fri, 21 Jul 2017 23:31:28 -0500 > > From: joshua stein <j...@openbsd.org> > > > > ACPI 4.0 deprecated _BIF for battery status, so some newer machines > > have _BIX instead which provides the

acpibat: add _BIX support

ACPI 4.0 deprecated _BIF for battery status, so some newer machines have _BIX instead which provides the same info plus some extra fields. I used some macro magic to make the diff less painful, and added a sensor for the new cycle count exported by _BIX which can be useful to see. Index:

rasops: fix virtual console initialization

Only copy the console buffer contents to a rasops virtual console if it's the first one (visible). Otherwise all of the other virtual consoles initialize with the trailing end of the kernel messages and then getty writes over them, like this: https://imgur.com/a/mAXKf Index: dev/rasops/rasops.c

Re: Add RTL8153 support to ure(4)

On Fri, 10 Mar 2017 at 20:54:39 +0100, Mark Kettenis wrote: > Fairly straightforward port of the changes made to the FreeBSD driver. > Like re(4) this has a fairly incestious relationship with rgephy(4) as > it needs a similar hack to read the media status register. > > Tests, especially on

acpisbs/acpibat

In case the DSDT provides interfaces for both a Smart Battery and a normal one, probe for acpisbs first, if it attaches, make acpibat not match. Index: dev/acpi/acpi.c === RCS file: /cvs/src/sys/dev/acpi/acpi.c,v retrieving revision

Re: Xorg stipple

On Sun, 26 Feb 2017 at 10:43:50 +0100, Landry Breuil wrote: > On Wed, Mar 09, 2016 at 05:09:13PM -0600, joshua stein wrote: > > Is anyone seriously finding video/Xorg bugs through the default X > > stipple pattern anymore? Xorg changed the default to draw a black > > b

acpithinkpad: new hid

New ThinkPads use a different ACPI HID. Index: sys/dev/acpi/acpireg.h === RCS file: /cvs/src/sys/dev/acpi/acpireg.h,v retrieving revision 1.36 diff -u -p -u -p -r1.36 acpireg.h --- sys/dev/acpi/acpireg.h 10 Jul 2016 20:36:41

Re: inteldrm: setup backlight pwm alternate increment on backlight enable

On Fri, 10 Feb 2017 at 10:46:08 +0100, Peter Hessler wrote: > On 2017 Feb 10 (Fri) at 11:52:20 +1100 (+1100), Jonathan Gray wrote: > :On Thu, Feb 09, 2017 at 06:39:13PM -0600, joshua stein wrote: > :> I have no idea why there are chickens involved, but this fixes the > :> p

speed up rasops32

Some EFI framebuffers are very slow, so rather than sending every pixel of a character one at a time, send one row at a time. Under VMWare fusion, this change makes a kernel boot to userland more than 10 seconds faster. It also helps a noticeable bit on my MacBook Air before inteldrm takes over.

Re: acpi: pretend to be Darwin on Apple hardware

On Thu, 09 Feb 2017 at 18:30:59 -0600, joshua stein wrote: > Without this, my MacBook Air won't suspend properly (hangs calling > _PTS) and a similar change in Linux from 2014 (commit > 7bc5a2bad0b8d9d1ac9f7b8b33150e4ddf197334) notes that upon resume, > the Thunderbolt ports won't b

asmc: restore keyboard backlight on resume

After resume, the keyboard backlight is still off, so restore it (this was also helpful to figure out the machine was actually resuming). Index: sys/dev/isa/asmc.c === RCS file: /cvs/src/sys/dev/isa/asmc.c,v retrieving revision 1.30

inteldrm: setup backlight pwm alternate increment on backlight enable

I have no idea why there are chickens involved, but this fixes the problem on at least the MacBookAir7,1 (Broadwell) where upon S3 resume, the backlight value is treated as 0 or 100 despite reporting intermediate values, so if the backlight value was anything other than 100 at suspend time, the

acpi: pretend to be Darwin on Apple hardware

When running on machines with a hw_vendor of "Apple Inc." or "Apple Computer, Inc.", only return 1 for an OSI check of "Darwin" and not the other Windows variants. Code in the AML of the MacBookAir7,1 (most likely all Macs) does much different things when running on Darwin systems, but the AML

Re: acpiec: handle burst mode failure

On Fri, 08 Jul 2016 at 18:51:17 -0500, joshua stein wrote: > If the EC fails to go into burst mode for whatever reason, the Burst > Acknowledge byte will not be there to read, which means the status > won't have EC_STAT_OBF, which means acpiec_wait will spin forever, > hanging

Re: quiet legacy drivers on amd64

On Tue, 02 Aug 2016 at 12:30:51 +0200, Joerg Jung wrote: > > > Am 01.08.2016 um 23:14 schrieb joshua stein <j...@openbsd.org>: > > > > are these complaints really helpful on modern machines? > > Can't speak for clock. But I tend to not like this for n

Re: acpiec: handle burst mode failure

On Thu, 14 Jul 2016 at 16:31:32 -0500, joshua stein wrote: > Also, I just checked FreeBSD and they appear to do something similar > to my patch, where they check that the EC burst mode flag is set in > the status after trying to enable it: > > https://github.com/freebsd/freebsd/

Re: acpiec: handle burst mode failure

On Sat, 09 Jul 2016 at 16:32:15 -0700, Philip Guenther wrote: > No newer bios for this thing? :-( It is actually the open-source Chrome EC found on the Chromebook Pixel (among others), and according to the source code for the version on this machine, it did not implement burst mode in its ACPI

Re: acpiec: handle burst mode failure

On Fri, 08 Jul 2016 at 22:34:34 -0700, Philip Guenther wrote: > On Fri, Jul 8, 2016 at 4:51 PM, joshua stein <j...@openbsd.org> wrote: > > If the EC fails to go into burst mode for whatever reason, the Burst > > Acknowledge byte will not be there to read, which means the

  1   2   >