RandR CRTC/Output Leases Lands In X.Org Server

[phoronix]

Phoronix: RandR CRTC/Output Leases Lands In X.Org Server

One big piece of Keith Packard's work on improving Steam VR for Linux or particularly VR HMD handling is now merged to Git master...

http://www.phoronix.com/scan.php?page=news_item&px=RandR-Leases-Lands-In-X

[tildearrow]

Typo:

to a client f or direct access

By the way, why are we still calling it a CRTC?

[oiaohm]

By the way, why are we still calling it a CRTC?

Simple it would be too much of pain to rewrite everything to use new term.

Video display controller(VDC) would make more sense. In effect it would be rename everything in the code base called CRTC to VDC and have it keep on doing the same it was doing and hopefully not break insane number of applications.

You can call this one of the historic hang overs someone a long time ago choose the wrong term and we are kind of stuck with it.

[linuxgeex]

It's still called a CRTC because the vast majority of these controllers still do have support for VGA and NTSC/SECAM/PAL outputs - they are still actually Cathode Ray Tube Controllers, and they happen to also support a variety of non-CRT display outputs as well.

I'm looking forward to the possibility that this "Leases" support will finally become a viable alternative to Zaphod mode, and together with VGL, actually provide proper multiseat on modern display hardware.

[oiaohm]

It's still called a CRTC because the vast majority of these controllers still do have support for VGA and NTSC/SECAM/PAL outputs - they are still actually Cathode Ray Tube Controllers, and they happen to also support a variety of non-CRT display outputs as well.

Video display controller(VDC) is the older term Xerox PARC called it VDC to control a Cathode Ray Tube. Sometimes picking the so call modern term long term makes you look like a goose and with the usage of the term CRTC is very much this as CRTC was the more modern term at one point.

To be correct producing NTSC, SECAM and PAL is not controlling a CRT. The true CRTC in case of NTSC, SECAM and PAL is inside CRT monitor that turns those signals into CRT tube signals. Sorry your example is when the term VDC should have been used. But we cannot alter historic mistakes now without a lot of pain.

[linuxgeex]

Video display controller(VDC) is the older term Xerox PARC called it VDC to control a Cathode Ray Tube. Sometimes picking the so call modern term long term makes you look like a goose and with the usage of the term CRTC is very much this as CRTC was the more modern term at one point.

To be correct producing NTSC, SECAM and PAL is not controlling a CRT. The true CRTC in case of NTSC, SECAM and PAL is inside CRT monitor that turns those signals into CRT tube signals. Sorry your example is when the term VDC should have been used. But we cannot alter historic mistakes now without a lot of pain.

Correction: NTSC, PAL, and SECAM are derived from CRTC signals generated by video hardware on the computer side of the wire. These are then time division multiplexed to a single signal to make it convenient and efficient to broadcast within roughly 3.5MHz of bandwidth, and then overlaid with an FM subcarrier and a quadrature-related color phase signal AKA "color burst". This standard was created in 1940, a tiny wee bit before the Alto, and was used by computers before the Alto existed.

Nobody is arguing that VDC is a more correct and modern over-arching term for all forms of hardware responsible for video scan-out. It is definitely the new standard, and is synonymous with CRTC in industry.

All I'm saying is that it's far from incorrect when talking about modesetting heads to refer to CRTCs (the job inevitably involves calculating timings compatible with Cathode Ray Tube Controllers for backwards compatibility) and the vast majority of display hardware still produces CRTC signals.

VDC is a better term, but CRTC wasn't as wrong as most of the people who mentioned it were suggesting it was. I'm confident that if it was entirely wrong the DRM maintainers would simply run a sed script on the DRM tree and offer that sed script for developers to fix dependent software after the fact. It would not be as much of a growing pain as it sounds. The amount of software that talks directly to DRM is quite small.

TBH I think we should go back to the term "Display Controller", which is even more generic, and applies much better to IOT displays, headsets, etc, which are not really "video displays".

[oiaohm]

Correction: NTSC, PAL, and SECAM are derived from CRTC signals generated by video hardware on the computer side of the wire. These are then time division multiplexed to a single signal to make it convenient and efficient to broadcast within roughly 3.5MHz of bandwidth, and then overlaid with an FM subcarrier and a quadrature-related color phase signal AKA "color burst". This standard was created in 1940, a tiny wee bit before the Alto, and was used by computers before the Alto existed.

This does not change what I said. Might be base off what a CRTC controller need to send to screen but they are not CRTC. The basic thing to be a CRTC is be connected to a ray tube. There are a few computer monitor signal systems where you can in fact have direct wires from the video card to the CRT those are true CRTC.

VDC is a better term, but CRTC wasn't as wrong as most of the people who mentioned it were suggesting it was. I'm confident that if it was entirely wrong the DRM maintainers would simply run a sed script on the DRM tree and offer that sed script for developers to fix dependent software after the fact. It would not be as much of a growing pain as it sounds. The amount of software that talks directly to DRM is quite small..

It does not matter who you attempt to save this. If you get out the term dictionary and look up what CRTC proper means the usage in Linux is wrong. But people use like the term wicked for good at times. Humans don't always use terms correctly. Does not mean we should not be truthful with each other.

The reason why the term has not been correct in the Linux kernel. Is Linus Rule Never ever break user experience. Remember Linus Rule means that the Linux kernel doing stuff technically wrong so user-space stuff works is in fact acceptable.

The term CRTC is used wrong in the first Linux kernel framebuffer subsystem. Now using 1 term in framebuffer system and another term in the DRM system for the something could make things confusing. The history of getting framebuffer subsystem and DRM on the same page is a history of up hill battle.

Also to be really horible is not just the Linux kernel that has used CRTC term wrong. You find CRTC is documentation from hardware vendors and in Microsoft Windows used wrong.

https://docs.microsoft.com/en-us/windows-hardware/drivers/display/introduction-to-video-present-networks

Its basically at a particular point in time the term CRTC was used wrong and we are stuck with it for now. CRTC term is one of times in the computer world that like the usage of wicked being good where it usage does not match the meaning at all.

When a term as been used wrong as long as CRTC has to correct can be next to impossible because you need a great number of parties to agree that they have been writing stuff wrong what is bad for those parties reputation. But this does not mean we cannot be truthful that the usage is wrong and work with it that way anyhow.

TBH I think we should go back to the term "Display Controller", which is even more generic, and applies much better to IOT displays, headsets, etc, which are not really "video displays".

Video displays that VDC covers is fairly much anything that anything you send frame after frame to. As that is the basic old define of video. So most headsets and head up displays are video displays. Its like the split between text based printers and graphical printers.

[linuxgeex]

Video displays that VDC covers is fairly much anything that anything you send frame after frame to. As that is the basic old define of video. So most headsets and head up displays are video displays. Its like the split between text based printers and graphical printers.

Originally with CRTC we were sending the display electric signals which directly drove beam timing, position, and intensity.

With VDC there's a layer of abstraction and instead the common jobs are sending mode setup commands and raster packets.

VDC is getting progressively more abstract. Display setup commands are digital. Raster packets are digital and losslessly compressed to save power and increase effective bandwidth. The VDC is less and less aware of what is being fed to it and what it is driving. VGA and Component signals definitely had a CRT in mind when they were created, and those signals directly control beam intensity, position, and timing. MIPI DSI has a pretty good idea that it is talking to an LCD panel and has nothing whatsoever to do with CRTC, but it still has specific timings that need to be met. Thunderbolt on the other hand makes a lot less assumptions - you can plug in a display, a USB dongle implementing a display, a PCI card with dedicated GPU implementing multiple heads, or all of the above and then some.

How does that work? Basically it boils down to hardware networking routing and VDC hardware in the displays themselves, and the kernel implementing drivers, which really just feed packets to the display hardware. The driver implements software-defined display heads. According to you we can't call them VDC because they aren't VDC's - those are only in the physical displays, or in the display adapter driving the physical display, not in the kernel itself. But we have to call them something.

We've been calling them CRTCs. I myself would prefer that they call it a Display Controller. Video implies a 2D rectiliear surface with > 12 FPS raster updates. I think the future has more in store for us.

Maybe let's propose to call it a Virtual Display Controller, because I know a guy who is absolutely dead-set on calling it a VDC. ;-)

[oiaohm]

We've been calling them CRTCs. I myself would prefer that they call it a Display Controller. Video implies a 2D rectiliear surface with > 12 FPS raster updates. I think the future has more in store for us.

http://www.newhavendisplay.com/nhd0440azflybw-p-437.html?zenid=490gn09nk6de1abmi040a7e7u3

I will make it a little clear for you. Above is a Display that has a Display Controller. One catch it only displays 4x40 text.

So you have Text Display Controller(TDC) that only can display a limit form of text then you have Video Display Controller(VDC) that covers graphical. Display Controller covers both. These are the old defines. We don't talk about TDC very much any more.

Sorry epaper that could be doing 1 frame per year would still be called Video Display Controller.

[linuxgeex]

http://www.newhavendisplay.com/nhd0440azflybw-p-437.html?zenid=490gn09nk6de1abmi040a7e7u3

I will make it a little clear for you. Above is a Display that has a Display Controller. One catch it only displays 4x40 text.

So you have Text Display Controller(TDC) that only can display a limit form of text then you have Video Display Controller(VDC) that covers graphical. Display Controller covers both. These are the old defines. We don't talk about TDC very much any more.

Sorry epaper that could be doing 1 frame per year would still be called Video Display Controller.

I get that. But did you get your own argument was that there's no CRTC on the kernel side of the cable? In fact, the DRM has no VDC either. The DRM has a software API which provides a hardware-agnostic way to map a region of memory to a display, set up the resolution and timings, even power it on and off, and each of those displays is referred to as a CRTC simply because that is what it originally drove. There's a lot of instances of adoption of incorrect terms which people have become comfortable with and will probably never change... "Jacuzzi" became a common name for a hot-tub, "Crock-pot" for a slow cooker, or "Seeing Eye Dog" for guide dog... They're all used inappropriately 99% of the time. The difference is, most display hardware is still actually generating CRTC signals, so it's less wrong than calling the cup you drank your beer out of a "Styrofoam cup" when it's actually an expanded polystyrene cup, and contains zero Styrofoam whatsoever, lol.