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 becaus
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
==
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 (*
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 uhi
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 dev
rs;
> +
> + if (config_found(sc->sc_iic, &ia, dwiic_i2c_print)) {
> + node->parent->attached = 1;
> + return 0;
> + }
> +
> + return 1;
> +}
> +
> int
> dwiic_acpi_found_iatp(struct dwiic_softc *sc, struct aml_nod
+ * Elan I2C Touchpad driver
*
* Copyright (c) 2015, 2016 joshua stein
* Copyright (c) 2020, 2022 Vladimir Kondratyev
@@ -19,9 +19,10 @@
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
-/* Protocol documentation: https://lkml.indiana.edu/hypermail/linux/kernel
On Thu, 17 Aug 2023 at 16:12:07 +0900, YASUOKA Masahiko wrote:
> Hi,
>
> Update the AC status when the battery notification is happened.
> Because the AC status notification doesn't happen on some machines.
> My vaio actually has this problem.
>
> Also Linux is doing the same thing
>
> https://g
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 glo
\
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
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
share/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 an
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
> rea
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 l
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
> o
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
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
--- usr.bin/us
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
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
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 comes
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 byte
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:
> >
> >
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
reso
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 threa
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
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 a
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 -
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 t
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).
This
-
@@ -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
+.\" copyright n
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.
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,// Usag
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 t
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.
lug.c 2 Sep 2018 17:42:50 -
@@ -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
@
s/dev/i2c/imt.c
index 38169837338..5a699921498 100644
--- sys/dev/i2c/imt.c
+++ sys/dev/i2c/imt.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/dn4
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 whi
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 I
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
===
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 le
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.
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.
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 snoo
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.
>
>
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
==
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
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
--- lib/libutil/log
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
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
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.
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 cust
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
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 put
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 defeat
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
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
+++ arch/amd64/amd64/ef
On Tue, 17 Apr 2018 at 07:52:28 +0200, Mark Kettenis wrote:
> > Date: Mon, 16 Apr 2018 10:45:52 -0500
> > From: joshua stein
>
> Does this do the right thing for early consoles? The initial
> efifb_bs[] doesn't have space for the scrollback. At the point where
>
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()
{
cha
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 /tmp
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
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 (whic
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 di
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
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 use
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 sce
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.
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 2
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@. So
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
&
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 chu
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 rev
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
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
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
> > --- stdlib/po
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: dev/acp
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
> >
> > ACPI 4.0 deprecated _BIF for battery status, so some newer machines
> > have _BIX instead which provides the same info plus some ext
Removes this useless error that appears on some modern machines:
RTC BIOS diagnostic error
ff
Index: sys/arch/amd64/isa/clock.c
===
RCS file: /cvs/src/sys/arch/amd64/isa/clock.c,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 cl
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)
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 o
On Wed, 18 May 2016 at 09:33:36 -0400, Bryan C. Everly wrote:
> 2. The keyboard works at the boot prompt, but does not work once the
> install/upgrade/shell prompt comes up
The keyboard and trackpad appear to be connected over SPI:
https://bugzilla.kernel.org/show_bug.cgi?id=99891
While there m
On Thu, 09 Jun 2016 at 19:04:27 +0200, Ingo Schwarze wrote:
> Hi Gerhard,
>
> Gerhard Roth wrote on Wed, Jun 08, 2016 at 03:08:52PM +0200:
>
> > +.\" Copyright (c) 2016 genua mbH
> > + * Copyright (c) 2016 genua mbH
>
> These kinds of Copyright notices without the name of the actual author
> are
ll 1 Jan 1970 00:00:00 -
+++ arch/amd64/amd64/cbfb.c 10 Jun 2016 17:35:38 -
@@ -0,0 +1,447 @@
+/* $OpenBSD$ */
+
+/*
+ * Coreboot framebuffer console driver
+ *
+ * Copyright (c) 2016 joshua stein
+ * Copyright (c) 2015 YASUOKA Masahiko
+ *
+ * Permission to use, copy, m
nsole driver
+ *
+ * Copyright (c) 2016 joshua stein
+ * Copyright (c) 2015 YASUOKA Masahiko
+ *
+ * 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 appe
On Tue, 14 Jun 2016 at 07:22:14 +0200, Joerg Jung wrote:
> > We should not get hung up too much about the driver name. If it is
> > felt that efifb(4) is inappropriate for these chromebooks with
> > coreboot, we can always rename the driver.
>
> Yes, renaming makes sense then.
Any ideas for a ne
On Mon, 13 Jun 2016 at 12:35:23 +0200, Mark Kettenis wrote:
> > Date: Sun, 12 Jun 2016 11:47:37 -0500
> > From: joshua stein
> >
> > Here's a new version with feedback from Miod and Ted.
> >
> > It also fixes a bug on a Broadwell Chromebook (tested by
@@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2016 joshua stein
+ *
+ * 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 notice appear in all copies.
+ *
+ * THE
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 the machine.
This at least gets us moving again, ignoring the failure to enter
burst mo
On Fri, 08 Jul 2016 at 22:34:34 -0700, Philip Guenther wrote:
> On Fri, Jul 8, 2016 at 4:51 PM, 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'
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
in
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/
On Tue, 02 Aug 2016 at 12:30:51 +0200, Joerg Jung wrote:
>
> > Am 01.08.2016 um 23:14 schrieb joshua stein :
> >
> > are these complaints really helpful on modern machines?
>
> Can't speak for clock. But I tend to not like this for nvram.
> IMHO, even with re
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,
> ha
On Wed, 07 Sep 2016 at 11:18:57 +0200, Andreas Bartelt wrote:
> yes, due to the larger internal state of the blowfish algorithm which is
> harder to efficiently realize in dedicated hardware. However, since bcrypt's
> internal state effectively is of fixed size, scrypt would be an even better
> opt
8:09 -
@@ -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
*
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 t
C controller
+ * PCI attachment
+ *
+ * Copyright (c) 2015-2017 joshua stein
+ *
+ * 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 notice appear in all
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
> >
> > On my Kaby Lake laptop, running xbacklight or xrandr causes the
> > audio and mouse cursor to pause briefly. This is because those
&
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
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
+ *
+ * Permission to use, copy
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 unt
1 - 100 of 135 matches
Mail list logo