4 ms·

When a driver challenges the kernel's assumptions

81 points by todsacerdoti 10mo ago

Ericson2314 10mo ago
> The answer was as unhelpful as possible Uh I think I think that's way too mean to the email. From a random web form they got some technical information, a useful CC, and offer to have a call. Not bad at all! Also, my basic theory about hardware problems is that the problem is less that they won't share the docs, and more that even the internal docs suck. When you essentially co-evolve devices and software through many revisions of each over many years, it's easy to get a complete mess that nobody understands. (Of course, in this specific case, DisplayLink was new, so it's maybe less of a problem.)
- saagarjha 10mo ago
  I think they’re upset that the library was to be released under LGPL or whatever, even though they clearly went and read from it anyway when implementing their thing.
  - kimixa 10mo ago
    It seems they're pretty directly admitting to referring to the LGPL library while implementing theirs under a different license. I wonder if they'll have no issues with people directly reading their code while happening to implement the same functionality with a closed license? Or a GPL-style one? I'm surprised they admitted to it - it's hardly "Clean Room"....
    - messe 10mo ago
      > I'm surprised they admitted to it - it's hardly "Clean Room".... "Clean Room" RE isn't always legally required.
      - kimixa 10mo ago
        Not in RE, maybe, but directly viewing source isn't RE either.
        messe 10mo ago
        > but directly viewing source isn't RE either. I'd argue that it is. I'd also argue that directly viewing the source doesn't mean you can't write a non-infringing driver. Unless the source is owned by Oracle, in which case, my hourly rate goes up 100x.
        t-3 10mo ago
        The source and the machine code generated from it are logically equivalent (hopefully). Legality and effort required may be a different matter, but from a common-sense point of view there's little difference.
    - aulin 10mo ago
      Seems to me the most expectations they had with the library was about the compression stuff and it did not include that. So in the end it was mostly rev eng. Also in this specific case you are using the library code as documentation about the hardware, the code itself has little value. I doubt it would configure as license violation.
darig 10mo ago
[dead]
shmerl 10mo ago
> The answer was as unhelpful as possible Looking at the answer, I wouldn't call it unhelpful. They were planning to release a source for the library that would essentially implement all the needed data interfaces? That's more than helpful and at least they responded. I tried contacting Nuvoton for example about their documentation for some of their super I/O chips which lack Linux support (they do document a bunch of their chips pretty well, but for some weird reason not all). Not only I got no details, I literally didn't even get a response from them at all. So above case is hugely better.
- heavyset_go 10mo ago
  Go through the Linux Foundation, they have a process for accessing docs for drivers that vendors normally require NDAs with established businesses for, and won't offer random people.
  - shmerl 10mo ago
    If they require an NDA, they'll probably refuse to provide it for the purpose of Linux drivers? Unless it's just some dumb formality. I can try Linux Foundation.
    - heavyset_go 10mo ago
      Yeah it depends on their stance, some vendors just want an entity that can be bound by contract and they could theoretically sue if you leak their docs, and the Linux Foundation can serve that role. More info here: https://www.linuxfoundation.org/legal/nda https://www.linuxfoundation.org/legal/nda
      - shmerl 10mo ago
        Thanks for the pointer!
    - amluto 10mo ago
      This is definitely not true. It’s even sometimes possible to negotiate contract and NDA terms with Large Corporations for the specific purpose of producing open source code based on NDA specs. Source: been there, done that.
wzdd 10mo ago
Currently all the comments are either talking about whether DisplayLink's emails were helpful or nit-picking the aesthetics of the site, so just to get technical... While adding pause / resume functionality certainly solves the problem, it does seem like not the best possible solution. Firstly, it's a rather far-reaching change. Prior to this work TTY updates always succeeded, but now the kernel has to be aware that they can fail just in case userspace is talking to a DisplayLink (which the article acknowledges are increasingly rare)? We have a new type of wait queue (or wait type) for "waiting on TTY operation"? Secondly, the parallel with serial (heh) links isn't great because with a serial link you have no idea what the other side is doing with the data, so you can't make any assumptions. But for a TTY you know its dimensions and furthermore you're the one doing the terminal emulation, so a) there's a bound (and quite a small one) on the amount of data you need to buffer and b) you know exactly how the data is going to be presented because you're the one doing the presentation. So there is an opportunity here to be more efficient than just forcing userspace to halt. A good analogy would be an X terminal emulator which faithfully draws every line of text, even if it's scrolling past hundreds of times faster than a human could read, versus one which updates its buffer as fast as possible, even if it's only redrawing at the display refresh rate -- the latter performs much better because it only shows the data that ultimately matters! In particular, non-DisplayLink TTY drivers behave more like that performant X terminal emulator, because they're writing directly to graphics memory. Treating DisplayLink like a serial terminal makes it slower than it should be in the event of a lot of data being written; it is doing all its updates, even if they are immediately overwritten. A more performant approach would be to store two text buffers, one for the current state (ie what DisplayLink is dipslaying) and another for the desired state. Diff the two to determine what to update when the DisplayLink is ready again. It seems like this is basically what happens in graphics mode anyway, with dirty rects (which would just become larger dirty rects basically until the DL is ready for more commands) -- i.e. you have to buffer anyway for efficient blit / readback etc. If diffing textmode feels too much like policy, make a user-space component. Or do what graphics mode does and use just one buffer with a bounded set of dirty rects. In other words, it seems like a solution which came from "we are deep in the bowels of the device driver, what is simplest possible thing we can do?" and there's nothing wrong with that, but it does end up moving complexity elsewhere somewhat.
jeroenhd 10mo ago
> The usefulness of these devices has apparently gone away, people do not seem to be interested by these devices anymore those days. While USB-C and DisplayPort have taken over most external displays these days, plenty of all-in-one USB docks still use DisplayLink. Not every device supports DP ALT mode, and some devices (like several of Apple's M chips) don't support more than one external display over DisplayPort, making it a necessity to fall back to alternatives like DisplayLink.

81 points by todsacerdoti 10mo ago

> The answer was as unhelpful as possible Uh I think I think that's way too mean to the email. From a random web form they got some technical information, a useful CC, and offer to have a call. Not bad at all! Also, my basic theory about hardware problems is that the problem is less that they won't share the docs, and more that even the internal docs suck. When you essentially co-evolve devices and software through many revisions of each over many years, it's easy to get a complete mess that nobody understands. (Of course, in this specific case, DisplayLink was new, so it's maybe less of a problem.)

saagarjha 10mo ago
I think they’re upset that the library was to be released under LGPL or whatever, even though they clearly went and read from it anyway when implementing their thing.
- kimixa 10mo ago
  It seems they're pretty directly admitting to referring to the LGPL library while implementing theirs under a different license. I wonder if they'll have no issues with people directly reading their code while happening to implement the same functionality with a closed license? Or a GPL-style one? I'm surprised they admitted to it - it's hardly "Clean Room"....
  - messe 10mo ago
    > I'm surprised they admitted to it - it's hardly "Clean Room".... "Clean Room" RE isn't always legally required.
    - kimixa 10mo ago
      Not in RE, maybe, but directly viewing source isn't RE either.
      - messe 10mo ago
        > but directly viewing source isn't RE either. I'd argue that it is. I'd also argue that directly viewing the source doesn't mean you can't write a non-infringing driver. Unless the source is owned by Oracle, in which case, my hourly rate goes up 100x.
      - t-3 10mo ago
        The source and the machine code generated from it are logically equivalent (hopefully). Legality and effort required may be a different matter, but from a common-sense point of view there's little difference.
  - aulin 10mo ago
    Seems to me the most expectations they had with the library was about the compression stuff and it did not include that. So in the end it was mostly rev eng. Also in this specific case you are using the library code as documentation about the hardware, the code itself has little value. I doubt it would configure as license violation.

darig 10mo ago

[dead]

shmerl 10mo ago

> The answer was as unhelpful as possible Looking at the answer, I wouldn't call it unhelpful. They were planning to release a source for the library that would essentially implement all the needed data interfaces? That's more than helpful and at least they responded. I tried contacting Nuvoton for example about their documentation for some of their super I/O chips which lack Linux support (they do document a bunch of their chips pretty well, but for some weird reason not all). Not only I got no details, I literally didn't even get a response from them at all. So above case is hugely better.

heavyset_go 10mo ago
Go through the Linux Foundation, they have a process for accessing docs for drivers that vendors normally require NDAs with established businesses for, and won't offer random people.
- shmerl 10mo ago
  If they require an NDA, they'll probably refuse to provide it for the purpose of Linux drivers? Unless it's just some dumb formality. I can try Linux Foundation.
  - heavyset_go 10mo ago
    Yeah it depends on their stance, some vendors just want an entity that can be bound by contract and they could theoretically sue if you leak their docs, and the Linux Foundation can serve that role. More info here: https://www.linuxfoundation.org/legal/nda https://www.linuxfoundation.org/legal/nda
    - shmerl 10mo ago
      Thanks for the pointer!
  - amluto 10mo ago
    This is definitely not true. It’s even sometimes possible to negotiate contract and NDA terms with Large Corporations for the specific purpose of producing open source code based on NDA specs. Source: been there, done that.

wzdd 10mo ago

Currently all the comments are either talking about whether DisplayLink's emails were helpful or nit-picking the aesthetics of the site, so just to get technical... While adding pause / resume functionality certainly solves the problem, it does seem like not the best possible solution. Firstly, it's a rather far-reaching change. Prior to this work TTY updates always succeeded, but now the kernel has to be aware that they can fail just in case userspace is talking to a DisplayLink (which the article acknowledges are increasingly rare)? We have a new type of wait queue (or wait type) for "waiting on TTY operation"? Secondly, the parallel with serial (heh) links isn't great because with a serial link you have no idea what the other side is doing with the data, so you can't make any assumptions. But for a TTY you know its dimensions and furthermore you're the one doing the terminal emulation, so a) there's a bound (and quite a small one) on the amount of data you need to buffer and b) you know exactly how the data is going to be presented because you're the one doing the presentation. So there is an opportunity here to be more efficient than just forcing userspace to halt. A good analogy would be an X terminal emulator which faithfully draws every line of text, even if it's scrolling past hundreds of times faster than a human could read, versus one which updates its buffer as fast as possible, even if it's only redrawing at the display refresh rate -- the latter performs much better because it only shows the data that ultimately matters! In particular, non-DisplayLink TTY drivers behave more like that performant X terminal emulator, because they're writing directly to graphics memory. Treating DisplayLink like a serial terminal makes it slower than it should be in the event of a lot of data being written; it is doing all its updates, even if they are immediately overwritten. A more performant approach would be to store two text buffers, one for the current state (ie what DisplayLink is dipslaying) and another for the desired state. Diff the two to determine what to update when the DisplayLink is ready again. It seems like this is basically what happens in graphics mode anyway, with dirty rects (which would just become larger dirty rects basically until the DL is ready for more commands) -- i.e. you have to buffer anyway for efficient blit / readback etc. If diffing textmode feels too much like policy, make a user-space component. Or do what graphics mode does and use just one buffer with a bounded set of dirty rects. In other words, it seems like a solution which came from "we are deep in the bowels of the device driver, what is simplest possible thing we can do?" and there's nothing wrong with that, but it does end up moving complexity elsewhere somewhat.

jeroenhd 10mo ago

> The usefulness of these devices has apparently gone away, people do not seem to be interested by these devices anymore those days. While USB-C and DisplayPort have taken over most external displays these days, plenty of all-in-one USB docks still use DisplayLink. Not every device supports DP ALT mode, and some devices (like several of Apple's M chips) don't support more than one external display over DisplayPort, making it a necessity to fall back to alternatives like DisplayLink.