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.
> In fact, I think the first photo used outpainting
And it looks bad. The streetlamps on the right are way too close together and the building on the left looks like a prison or something out of Dickens.
I think this is precisely why I locked in so hard on the essay; I got suspicious right from the gate. Interesting troll to have uncanny valley AI about a real and unusual thing right up front. There should be a word for it.
Python got this right. Zero-based indexing combined with half-open slice notation means as a practical matter you don't see too many -1s in the code. Certainly far fewer than when I wrote a game in Löve for a gamejam, where screen co-ordinates are naturally zero-indexed, which has implications for everything onscreen (tile indices, sprites, ...)
Nobody actually productively commenting in the thread thinks it's a conspiracy theory and everyone acknowledges that the Apple hardware is off-spec. It would be nice to see Android add this workaround.
You have linked me to what sounds like an AI generated comment. AI comments cannot be trusted. AI will make up believable sounding gunk and cannot be trusted.
Last Chance to See has a fun bit about listening for dolphins in the Yangtze by taking a regular microphone and putting a condom over it. Always wondered how they sealed the end.
what if you tied it tightly beneath the mic with a rubber band, and then attached a weight 2-3 feet down the cord? that way the condom/mic floats end down and keeps things dry.
If you're 12 years old and it's the family computer (which I suspect was a not-insignificant part of the target market), you've also got to negotiate opening it up and sticking in a circuit board, adding drivers (and thus becoming prime suspect in every subsequent Windows crash), and finding some way of actually vibrating the air, which at the very least involves buying desk speakers and negotiating space on a desk which might not be your own.
I honestly didn’t think about the “needing external speakers part”.
The motherboard on the Mac had an internal audio input slot you connected the CD player to for audio CD playback. You also connected the DOS card’s SoundBlaster daughtercard directly to the motherboard and you could play PC sounds directly through the Mac speaker.
Entertaining that the article about copyright-infringing similarity of AI-generated summaries is illustrated with a picture of an animated skeleton labelled "White Walker", which is neither what White Walkers are nor what they look like.
> Entertaining that the article about copyright-infringing similarity of AI-generated summaries is illustrated with a picture of an animated skeleton labelled "White Walker", which is neither what White Walkers are nor what they look like.
Also "reading Wikipedia" by staring at the back of a tablet.
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.
reply