> On 13 Jun 2019, at 22:25, Bryan Steele <[email protected]> wrote:
>
> 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.
>
OK yes, I remember seeing something about it. Will give that a try. Much
better then opening up :)
>> 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.
Much appreciated, will try this and report the outcome.
>
> -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);
> }
>
>
