Announcement

Collapse
No announcement yet.

DisplayLink Releases First USB 3.0 Driver, But Doesn't Appear Fully Open

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DisplayLink Releases First USB 3.0 Driver, But Doesn't Appear Fully Open

    Phoronix: DisplayLink Releases First USB 3.0 Driver, But Doesn't Appear Fully Open

    A few days after writing about a Linux driver coming for DisplayLink's USB 3.0-based hardware, they've released a binary driver for Ubuntu...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I've checked it, and it is completely open. http://support.displaylink.com/knowl...rticles/679060 has one flaw and that is if you omit the target directory (--target extractdir), it actually won't do anything.
    The kernel driver is at: https://github.com/DisplayLink/evdi and
    Oh wait...
    Sheez...
    ard@odroid3:~/tmp/poep/test$ ldd x86/DisplayLinkManager
    not a dynamic executable
    ard@odroid3:~/tmp/poep/test$ ldd x64/DisplayLinkManager
    not a dynamic executable
    Forget it... Don't buy them. They won't work. It's a joke, just like openmax.

    Comment


    • #3
      Originally posted by Ardje View Post
      The kernel driver is at: https://github.com/DisplayLink/evdi
      Hah, looks like uinput/fuse/etc but for drm. All the logic for interacting with the device is in their closed blob library, the "evdi" thing is just an ioctl passthrough.

      Comment


      • #4
        Originally posted by imirkin View Post

        Hah, looks like uinput/fuse/etc but for drm. All the logic for interacting with the device is in their closed blob library, the "evdi" thing is just an ioctl passthrough.
        Actually, it's worse.

        The drm node (/dev/dri/card<num>) also acts as communication port to the proprieatary DisplayLinkManager, using driver specific ioctls. Think of reusing /dev/input/event<num> for pushing uinput data.

        Comment

        Working...
        X