On Thu, Jun 13, 2019 at 08:39:48PM +0200, Tristan wrote:
> Hi there,
> 
> I got a new lenovo v330-14 it has an AMD Ryzen 5 2500U and Radeon RX Vega 8
> and so was looking forward to using OpenBSD on this one. I'm currently 
> running a
> snapshot I grabbed today. To get the screen working I had to set 
> machdep.allowaperture=2
> unfortunately, but it works now and great as well. Video seems smooth. Audio 
> works as well

You should avoid doing that -- see recent mailing lists post from Mark
Kettenis.

https://marc.info/?l=openbsd-misc&m=156029398905090&w=2

For Vega graphics you need to recompile your kernel with the amdgpu
driver lines uncommented, alternatively reinstall in UEFI mode to get the
efifb(4) driver instead. This is probably better as amdgpu support is
still a WIP.

> but the touchpad is not working at all. Wireless card does not work either, 
> but using the 
> ethernet port on it for now until I get an USB dongle for it.
> 
> wsconsctl | grep mouse gives me only:
> mouse.type=ps2
> 
> In the dmesg output I can see only:
> wsmouse0 at pms0 mux 0

Indeed, there's no pms(4) compatible touchpad on your machine. :-(

> "AMDI0010" at acpi0 not configured
> "SYNA2B3F" at acpi0 not configured

And instead requires a driver to attach to the I2C HID controler. AMD's
implementation seems to be somewhat compatible with dwiic(4) written by
jcs@, however interrupts are not working-- hangs the machine. It does
work if polling mode is forced.

This diff made the touchscreen and touchpad work be detected and mostly
work on my Huawei MateBook D (AMD), however with the touchpad it seems
to be break Tap-To-Drag. I don't know if this is a side effect of the
drivers polling, unlike the pms(4) support-- which is working on that
machine. We have no way to prefer one driver over other, which is why
I haven't sent this diff yet.

Let me know if it works at all for you.

-Bryan.

Index: dwiic_acpi.c
===================================================================
RCS file: /cvs/src/sys/dev/acpi/dwiic_acpi.c,v
retrieving revision 1.8
diff -u -p -u -r1.8 dwiic_acpi.c
--- sys/dev/acpi/dwiic_acpi.c   1 Jul 2018 11:37:11 -0000       1.8
+++ sys/dev/acpi/dwiic_acpi.c   5 Jun 2019 00:25:29 -0000
@@ -66,6 +66,7 @@ struct cfattach dwiic_acpi_ca = {
 };
 
 const char *dwiic_hids[] = {
+       "AMDI0010",
        "INT33C2",
        "INT33C3",
        "INT3432",
@@ -163,8 +164,11 @@ dwiic_acpi_attach(struct device *parent,
        dwiic_enable(sc, 0);
        dwiic_read(sc, DW_IC_CLR_INTR);
 
-       /* try to register interrupt with apic, but not fatal without it */
-       if (crs.irq_int > 0) {
+       /* XXX: AMD i2c controllers have a problem with interrupts enabled */
+       if (strcmp(sc->sc_hid, "AMDI0010") == 0)
+               sc->sc_poll = 1;
+       else if (crs.irq_int > 0) {
+               /* try to register interrupt with apic, not fatal without it */
                printf(" irq %d", crs.irq_int);
 
                sc->sc_ih = acpi_intr_establish(crs.irq_int, crs.irq_flags,
@@ -294,6 +298,9 @@ dwiic_acpi_bus_scan(struct device *iic, 
        struct dwiic_softc *sc = (struct dwiic_softc *)aux;
 
        sc->sc_iic = iic;
+       /* XXX: Workaround broken interrupts on AMD for i2c slave devices. */
+       if (strcmp(sc->sc_hid, "AMDI0010") == 0)
+               sc->sc_poll_ihidev = 1;
        aml_find_node(sc->sc_devnode, "_HID", dwiic_acpi_found_hid, sc);
 }
 

Reply via email to