- feeds
- popular
- recent
- reader
- about
- story
- technologies
- what is rss
- connect
- dmca
- contact
- Feed Preview LWN: Comments on "Atomic mode setting design overview, part 2"
Atomic mode setting design overview, part 2
Very nice read, Daniel, as the first article! Again I propose some small fixes. Typo: - requires a at least a few hundred + requires at least a few hundred I take it that "the acquire con...
Atomic mode setting design overview, part 2
Is there any simple code example of using atomic mode setting?
Atomic mode setting design overview, part 2
The more important part imo are SoC drivers, and there's a lot going on there. For the big desktop graphics drivers AMD has already decided to completely move to the upstream kernel driver ev...
Atomic mode setting design overview, part 2
Daniel, thanks for this great article series. Not only it summarizes the history and provenance of KMS, I also enjoyed reading a good piece of text (well, I'm actually used to greatly written ...
Locking
It takes a lock on the plane and on the crtc. If a plane is moved between crtc's the old and new crtc are both locked.
Locking
Ah - so the locking discussed in the article is not to arbitrate between multiple threads changing modes concurrently, but between a single thread changing mode and other threads performing simp...
Locking
no, but that it has a single main loop for all displays, rather than one per display, is.. I suppose you could work around it w/ async modeset (although that seems to open up a different can o...
Locking
That the modesetting is a blocking synchronous operation is not a fault of X...
Locking
We used to do that.. remember when framerate dropped every 10sec when hotplug poll loop tried to see if the monitor was still there? Granted, we managed to fix that without going *as* fine-gra...
Locking
The locking sounds complicated, even when mostly hidden in the helper libraries. What use-cases require fine-grained locking for plane or mode changes, ie why isn't it reasonable to just creat...