Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Red Hat Software Linux

Linux 5.17 To Introduce A New Driver Just To Deal With Buggy x86 Tablets (phoronix.com) 50

Phoronix reports: The Linux 5.17 kernel when it kicks off next month is slated to introduce a new driver "x86-android-tablets" just for dealing with all the quirky/buggy x86 tablets out there.

Longtime Linux developer Hans de Goede of Red Hat has been responsible for numerous x86 laptop/tablet improvements in recent years along with other desktop-related improvements at Red Hat. He has now queued up into the x86 platform drivers tree the x86-android-tablets driver he wrote for dealing with the mess of x86 (mostly Android) tablets that don't behave properly out-of-the-box with Linux.

As part of the ACPI DSDT (Differentiated System Description Table), many x86 tablets have simply invalid entries and other problems that cause issue when trying to run mainline Linux on said hardware. Hans explains as part of the commit currently in the platform-drivers-x86 "for-next" branch....

"This driver, which loads only on affected models based on DMI matching, adds DMI based instantiating of kernel devices for devices which are missing from the DSDT, fixing e.g. battery monitoring, touchpads and/or accelerometers not working."

This new x86-android-tablets driver will basically be a catch-all solution for overrides based on device matching. Hans ended the patch message with, "This is the least ugly option to get these devices to fully work and to do so without adding any extra code to the main kernel image (vmlinuz) when built as a module."

This discussion has been archived. No new comments can be posted.

Linux 5.17 To Introduce A New Driver Just To Deal With Buggy x86 Tablets

Comments Filter:
  • by rsilvergun ( 571051 ) on Sunday December 26, 2021 @09:49PM (#62118277)
    Remember installing Windows 95 or 98 and then racing off to install the VIA 4-in-1 driver before the buggy chipset took down the operating system. As near as I can tell it just disabled all the features that didn't work but the marketing people put on the front of the box for the motherboard. But you could get a VIA motherboard for about 1/3 the price of anything else so it was hard to argue with that.
    • by antdude ( 79039 )

      Yup. Hyperion. :O

    • I always paid more for the higher end ASUS and Intel boards, so I didn't have this problem. I hated working with the garbage components you described. I broke down and built one like that by special request. I regretted it continually until they finally threw it away.

      • by tlhIngan ( 30335 )

        I always paid more for the higher end ASUS and Intel boards, so I didn't have this problem. I hated working with the garbage components you described. I broke down and built one like that by special request. I regretted it continually until they finally threw it away.

        The garbage component in this case is the BIOS. The BIOS basically creates a massive data structure in memory that describes the hardware in the system (processors, memory, interrupt mappings, etc) so the operating system can detect and initial

    • God yes. I had a slot A athlon 750, but I was too poor to buy the AMD 751 northbridge chipset and bought a shitty Via KX133 based board instead.

      Buggiest piece of shit I've ever owned.

  • Comment removed (Score:4, Insightful)

    by account_deleted ( 4530225 ) on Monday December 27, 2021 @01:59AM (#62118523)
    Comment removed based on user account deletion
    • I'm also not certain that working around the bazillion buggy tablets - oh, sorry, it's x86 Android tablets, I meant eight buggy tablets - is a good idea, because now vendors have a free hand to keep releasing equally buggy tablets for the rest of eternity instead of sorting their shit out.
    • and companies still manage to fuck things up!

      Huh? We are fucking up? *glances over at large pile of money from Windows / Android sales* Nah it's good.

    • by dargaud ( 518470 )
      Yeah, don't know if it's related, but I have a brand new Dell laptop with Linux which keeps waking up (and staying up) in the bag. When I pull it out, it's boiling hot and the battery's drained... Trying to debug the issue has led nowhere as I can't find hints as to what is waking it up.
      • by ami.one ( 897193 )

        This shit happens to me too intermittently. Thinkpad yoga on Windows 11.
        I'll probably re-install win11 instead of finding out what the problem is.

        At times I have felt my bag/satchel feeling hot outside and checked to find its almost too hot to touch inside.
        After closing the laptop I have to wait few seconds and peek sideways inside the closed laptop to confirm its gone to sleep or started doing god knows what.
        People are always amazed invariably ask why dont i open it and see.
        But then i tend to install too m

        • by dargaud ( 518470 )
          Thanks for the suggestion, but I can't hibernate on this machine: only 1Gb of swap on a 32Gb machine. Anyway, one reason it wakes up is unplugging the monitors, so if I unplug first and shut the lid 2nd, it wakes more rarely.
      • Dell laptops have been doing that for decades. The only solution is to not put a Dell laptop in a bag.
    • by tlhIngan ( 30335 )

      Issues with bad ACPI DSDT and ACPI in general have been around ever since they first invented ACPI and there are still mobos, laptops and the likes suffering from it. I have myself had a couple of mobos in the past with all sorts broken ACPI-implementations and one of the mobos refused to work correctly with any OS, until I installed a modified BIOS with manually adjusted DSDT!

      It's kind of amazing how ACPI has been around for decades -- since 1996, specifically! -- and companies still manage to fuck things

    • by antdude ( 79039 )

      There will always be issues like this. :(

  • by peppepz ( 1311345 ) on Monday December 27, 2021 @04:38AM (#62118671)
    ...a driver for Intel storage in RST mode? Which is the default setup of the root storage for a large number of machines and makes it hard for people to install Linux on them? I think it's a similar situation, of badly designed hardware requiring ugly workarounds. As of now, one has to hack its Windows installation in order to install Linux alongside it.

    I know that asking other people to do work for me isn't exactly a nice thing to do, especially if said work consists in introducing ugly hacks, but... pretty please? :-)

    • The driver exists.
      The problem is that the kernel maintainers hate it.
      It requires support for neutering the NVMe layer, and the kernel devs refuse to accept patches that allow that to happen.

      Ultimately, RST is a pile of shit, and you should turn it off anyway.
      And yes, I know it's the default, and ya, I know it's a pain to move your factory Windows install off of it.
  • They're 100% designed this way to make it harder for non-native OS's to be installed on these things.

    I don't believe for a moment that this is an oversight, a bug, or a mistake.

  • This advice from opensource intel website seems easiest to try first.

    "acpidump is a tool that can be used to dump the ACPI tables provided by the BIOS. This is helpful when debugging suspend/hibernate problems that are probably caused by ACPI. To get the tool, just go to the tools/power/acpi/ directory of your kernel source code and run “make”."

    Maybe there is a cron job or some wakeon setting.

Avoid strange women and temporary variables.

Working...