Slashdot Mirror

There is a whitepaper with little detail: http://www.vesa.org/wp-content...

Reading that, it sounds pretty far from lossless. They say that it mostly worked at 8bpp, but wasn't perfect. So not visually lossless at all. They tested with still images too, no work on how it copes with movement. Could be some nasty artefacts as things change from frame to frame, much like how constant bitrate video gets noisy and then suddenly clears up as movement settles down.

Considering the effort require I'm surprised they bothered. I suppose it's a solution for small devices wanting to produce a pseudo 4k/120 or 8k/60 display, but that seems like a very small market.

As mentioned elsewhere in here, Thunderbolt is fine as it's an open spec and is intended for different use cases than USB, and it also shares a port design with mini-Displayport (which we can thank Apple for openly releasing that connector standard).

Last I heard, Thunderbolt 3 was going to need a new connector anyway.

Meanwhile, USB-C seems to have ambitions to replace DisplayPort cables as well. If I'm reading it right, it can use some of the physical wires for DisplayPort while leaving the rest for USB3 - c.f. Thunderbolt which either switches the entire connector to legacy DisplayPort mode or requires a TB controller at the receiving end to extract the DisplayPort signal. So we might see USB-C displays with integral USB hubs, webcam, microphones that can also charge your laptop, all over a single cable. OK, Thunderbolt can do most of that, but it can't power the computer and AFAIK after 4 years of Thunderbolt there are a grand total of 2 Thunderbolt displays on the market (Apple's which hasn't been updated since 2011 and doesn't even have USB3, and one LG model that just offers a USB3 hub).

They'll release new models with USB-C along with every other manufacturer as then every user can complain equally for the next couple years that they need all new cables and chargers.

From what I've seen, though, Apple's Lightning is often built into speakers, stereos, alarm clocks, car mounts etc. as a 'dock' (that does happen with microUSB but not so often). Replacing those is rather more annoying than having to buy new cables or chargers.

And USB 3 does not do everything I use Thunderbolt for on my Mac, including ferry USB3 over the same wire as video.

USB-C is in fact USB 3.1, and it very much does ferry USB and video over the same wire. VESA has standardized DisplayPort over USB-C. VESA's press release can be found here: http://www.vesa.org/news/vesa-... or AnandTech had a good article here: http://www.anandtech.com/show/...

and plug in my laptop with single cable and instantly my displays, USB3 devices, audio and networking all work ...

USB 3.1 has the same bandwidth as Thunderbolt 1 (10Gbps), there's no reason why a USB-C dock couldn't do all that, and be much cheaper than a Thunderbolt dock in the process.

USB-C also supports far more power delivery than Thunderbolt. Normal devices get up to 15W (Thunderbolt does ~10W), or devices can draw up to 100W if they implement v2 of the power delivery spec.

Thunderbolt is proprietary (although it isnt *Apples*) as is the 'mini display port' which is the only way to attach an external monitor.

The larger issue in my mind is the lack of standard ports. A notebook that has only one USB port, NO ethernet (the option to add it is with a dongle that will then occupy that single USB port,) and NO standard display port on it is pure fail, without even considering the lack of a replaceable battery.

Mini Displayport is a VESA standard, and a Mini Displayport to HDMI cable costs a grand total of $6.58 if you need one.

It's small and light which is wonderful, but in order to actually USE it one would have to first buy and then carry a second case full of dongles, adapters, USB hubs, and quickchargers, and at that point you might as well just buy a real laptop - the total package will be lighter and less bulky as well as less expensive.

Use it for what? Running a recording studio while on the train? What would you do that would require a bunch of USB peripherals while travelling? How many people need a wired ethernet connection when they're not at their desks?

So long as you're just doing "normal" stuff, you don't need to carry a damn thing except the computer itself. The battery is lasts up to 15 hours in real, actual testing, so you can use it all day. It lasts longer than other laptops even with external batteries.

... as is the 'mini display port' which is the only way to attach an external monitor ...

I'll just leave this (PDF warning) right here.

The issue is that practically nothing works perfectly out-of-the-box - unless you search and pay more and are lucky. Printers are just nice example.

I'm disagreeing with you on the facts here. If you have say a postscript printer on a network port:
1) generate postscript
2) send it as an unmodified stream to the printer (lp command that Unix has had 40 years works fine).

same with PCL, same with IPDS....
You don't need a driver at all. You just configure the printer raw. What plays the role of the driver on windows is on the printer itself. You completely eliminate the issue. Not only that you end up with a clean marriage between "print to file" and "print to paper" which allows for real proofing.

Back in the 1980s video cards used to all be proprietary and require all sorts of weird binary codes to get actual video. Applications programs that wanted to do video used to ship with their own video drivers and to use the app you installed the correct video driver for you hardware. Of course if the app didn't make the right video driver you either had to change video cards or use a different app or one of the other alternatives (right your own, use a video driver intended for another card and compensate, download one from a bbs...).

Then the standard video modes came out and for VGA, EGA, CGA this ended. And now you don't really need a video driver to do 2D graphics just about any card will accept a 640x480 signal in generic VGA format. And this has even been extended by VESA as resolutions went up to say UXGA (1600x1200) and all the others, so 2D graphics works fine "driverless".

Going back less far when monitors became multi mode each monitor started having monitor drivers which altered how the video card communicated with the monitor. Again standards eliminated this and today you can switch from monitor to monitor without worrying about the monitor's internal hardware.

Similarly for harddrives which used to require loading a driver into the bios which read the first track which loaded a driver into memory which gave you access to the whole drive. Linux used to have to deal with that, A Debian CD in the early 1990s was a large collection of extended floppy virtual images (2.88mb) capable of loading different harddrives to even make installation possible.

Printers have always had these generic modes (with some exceptions). Yeah the $50 inkjets don't support those modes because they are holding down the cost of hardware. In which case you need to be very careful or very skillful. My advice would be don't use those. There isn't a Linux problem with printers there is a Linux problem with Windows only printers. Unix printing never really bought into the Windows philosophy of hardware based print languages handled via. binary drivers.

I don't know anything about DVB but as I mentioned the drivers must exist and must be quite good since embedded Linuxes use them. If they exist, then OEMs who sell computers should compile the drivers for the DVB cards they sell into the kernels of the distributions they provide with their hardware. That's the Unix model for driver distribution when standards don't exist. I don't know why ASUS is not doing that, you could ask them. But the real Unix model is to have the "driver" exist on the hardware and for the OS to be getting a standardized stream and solve this issue forever.

1. VESA
2. The Open Group
3. IEEE
4. GSM
5. The Unicode Consortium
6. Bluetooth SIG
7. CAN
8. EIA (responsible for, among other things, JEDEC, who are responsible for DDR and related standards)

So the main reasoning this group is forwarding this new "interface standard" is not to improve your video quality, nor to make the cable smaller or easier to manage. Sure, those certainly are nice features, but it is not why they developed this new standard. From VESA:
"The promoter group based their development efforts on the premise that the PC industry requires a ubiquitous digital interface with optional content protection that can be deployed widely at minimum cost to enable broad access to premium content, according to Miller. "

One of the biggest reasons that many companies want a standard outside of DVI and HDMI is the fact that Silicon Image and Intel basically control the show when it comes to digital interfaces. Intel needs to be mentioned because, although Silicon Image appears to spearhead the standards and controls key patents (e.g. TMDS), Intel exerts a high level of influence due to partial ownership of Silicon Image and DCP LLC. In fact, if you look at DCP LLC's address at the bottom of its web page, it resides inside Intel!

When DVI first came out, it was in a camp that was separate from VESA, the independent standards body responsible for the video signalling standards for PCs. VESA had been looking for a digital alternative for years but the Digital Display Working Group promoted DVI through some of the bigger manufacturers of both computer displays and manufacturers of electronics of those displays. DVI was ok but it was plagued with problems like a poor quality connector, limited cable length and very poor standards compliance. This largely limited DVI's adoption in the market for a number of years. The copy protection standard, HDCP, was added in the usual fashion of trying to "protect" the content providers. As for the standards compliance, Silicon Image knew it had screwed up and so created a compliance test center. The irony here is that Silicon Image's own first generation receivers don't even work with some of its own transmitters!

Though most consumer electronics manufacturers were included in the DDWG, at least one was conspicuously absent during the formation of HDMI, which is backwards compatible with DVI but has a smaller and more robust connector and more geared for consumer electronics rather than PC applications. That absent company was Samsung, and Ian Miller of Samsung was quite important in the VESA organization. VESA had continued during the time of HDMI's creation and ramp-up of making a new standard, the latest one being NAVI that died on the vine. Having been excluded, and knowing Samsung's growing presence in many markets and the stranglehold of Silicon Image and Intel with respect to patents and copyright protection control with limp alternatives, I believe that the current companies within DisplayPort led by Ian Miller decided to take the initiative and move forward with an independent DisplayPort standard and independent copy protection mechanism. The new copy protection scheme, called DPCP, is administered by Philips rather than Intel.

The physical layer of DisplayPort is largely based on PCI Express in order to leverage the intellectual property already within these companies and avoid licensing and royalties associated with Silicon Image's TMDS and Intel's HDCP. One very interesting point for all /.ers - the interface standard is optionally encrypted with DPCP, but it can apply to every single link both outside and inside the display! This means that you may not be able to crack your panel open and hack the hardware inside without a hacked encryption key (which is heavily guarded at all points within its acquisition and programming into devices). Even with HDCP, it would be a simple matter in a flat panel to take the unencrypted LVDS output and fabricate a small board with an unencrypted DVI digital output for HDTV. Therefore, don't look at DisplayPort as anyone's savior. It also remains to be seen if people will accept yet another display connector for their PCs and the resultant fragmentation, though both ATI and Nvidia are on board DisplayPort.

In short, don't expect a whole lot of advantages for the end user here. The politics of the display industry are significant and the average consumer will continue to suffer as these politics play out in the grander scheme of business.

I'm no expert but I bet VESA sets those standards. They're in charge of everything else video-related. Note that the resolution combinations are all 4:3 or 16:9-10 proportions, the same as the monitors.

According to this page the new iMac has an optional VESAmount so it can easily be mounted in various configurations.

The display now only rotates in one single dimension

However, if you look at the right hand side of the graphics page at Apple, you will see that the entire machine can be VESA mounted, just like the new Cinema Displays.

from apple.com/imac

... but you can make that zero with an optional VESA mount. Hang it from the wall or swing it around on your desk.

So the mounts are already available.

I suspect it will come with VESA Plug and Display port instead, which includes Firewire and USB support. After all, it still has less clutter than DVI.

VESA is a standards orginization.

The VESA local bus was one (short lived) standard, as are the VESA 1.0, 2.0, 3.0 compliant display modes.

"VESA display modes" is absolutely correct. Try using google next time you want to sound like a techno whiz kid.

VESA did come up with a pre-PCI bus, but it's best known among users for standardizing the timings for video signals that weren't created by IBM (EGA, VGA, XGA, etc.) Check out www.vesa.org .

Okay, I don't have time to write a full treatise, so here's a quick overview of all the sTUfF involved. For the record, my job is writing graphics drivers for BeOS.

There are several constraints which need to be observed. These are:

• Minimum/maximum pixel clock rate of the card,
• Minimum/maximum horizontal rate of the monitor,
• Minimum/maximum vertical rate of the monitor.

Typically, the graphics driver will constrain the pixel clock rate, so the only thing left to worry about is monitor scan rates. The scan rates supported by your monitor are printed in your owner's manual.

Modern monitors also support DDC (Display Data Channel), which is a funky serial protocol to get identification and configuration information out of the monitor. The original DDC spec provided only for transmitting a unique monitor ID. The ID was supposed to be looked up in a database which would contain the monitor's min/max scan frequencies and other characteristics (can you say C:\WINDOWS\INF\MONITOR*.INF?). A more recent revision of the DDC spec now supplies these frequencies directly, as well as gamma characteristics and other cool stuff. Neither XFree86 nor BeOS support DDC yet.

Trivium: Absolutely every monitor out there will support 31.5 KHz horizontal, 60 Hz vertical. Unfortunately, this is only useful for 640 x 480. That's why Windoze defaults to this when it can't identify your monitor or graphics card; it knows this will work in any case.

Once you have a mode line for a particular resolution, you can not simply tweak the pixel clock. Sync timings vary not only by resolution, but also by scan rate. This is because the horizontal sync pulse is not simply a percentage of total horizontal time; it needs to be of a fixed duration, regardless of the scan frequency. If you stray outside the sync pulse requirements, the monitor's flyback transformer can overheat, shortening the monitor's life (and possibly killing it in ugly ways).

There are three ways "The Rest of the World" generates mode lines. One is via a direct DDC probe as outlined above. Another is to use the official mode table provided by VESA. This table contains fixed sync timings from 320 x 200 all the way out to 1900-something. Monitor manufacturers are supposed to make certain that their monitors respond well to these modes. When compiling their BIOS mode tables, however, some graphics card manufacturers, however, will make minor alterations to the VESA table, usually to the HSync and HTotal parameters. I've never discovered why they do this (except that if you don't, the graphics will come out looking funny in some cases).

The third way is to use the VESA GTF (General Timing Formula). This formula takes the following parameters:

• Desired display resolution,
• Desired (vertical scan rate OR horizontal scan rate OR pixel clock frequency)

From this, it will compute a mode line that will work on all modern monitors, and most old ones (too old to support DDC). The formula is rather ugly, involving a square root somewhere, and I don't have it in front of me.

Copies of the VESA mode tables, GTF, and DDC specs can all be ordered from VESA. I don't know offhand what, if anything, they charge to print up and send you a copy.

XFree86 should at least use the VESA mode table as a starting point for mode lines.

Schwab

...With a few Matrox modes thrown in. Enjoy. You can get a copy of the official VESA mode table (complete with all the fields I left out) from, of all places, VESA.

[[Rob, Hemos, et al: WTF happened to <PRE>?]]

/* Sync: n == negative, P == positive */
/* VESA: 640x480 @ 60Hz */
{ 25175, 640, 656, 752, 800, 480, 490, 492, 525, SYNC_HnVn}
/* VESA: 640x480 @ 72Hz */
{ 31500, 640, 664, 704, 832, 480, 489, 492, 520, SYNC_HnVn}
/* VESA: 640x480 @ 75Hz */
{ 31500, 640, 656, 720, 840, 480, 481, 484, 500, SYNC_HnVn}
/* VESA: 640X480 @ 85Hz */
{ 36000, 640, 696, 752, 832, 480, 481, 484, 509, SYNC_HnVn}
/* VESA: 800x600 @ 56Hz */
{ 36000, 800, 824, 896, 1024, 600, 601, 603, 625, SYNC_HPVP}
/* VESA: 800x600 @ 60Hz */
{ 40000, 800, 840, 968, 1056, 600, 601, 605, 628, SYNC_HPVP}
/* VESA: 800x600 @ 72Hz */
{ 50000, 800, 856, 976, 1040, 600, 637, 643, 666, SYNC_HPVP}
/* VESA: 800x600 @ 75Hz */
{ 49500, 800, 816, 896, 1056, 600, 601, 604, 625, SYNC_HPVP}
/* VESA: 800x600 @ 85Hz */
{ 56250, 800, 832, 896, 1048, 600, 601, 604, 631, SYNC_HPVP}
/* VESA: 1024x768 @ 60Hz */
{ 65000, 1024, 1048, 1184, 1344, 768, 771, 777, 806, SYNC_HnVn}
/* VESA: 1024x768 @ 70Hz */
{ 75000, 1024, 1048, 1184, 1328, 768, 771, 777, 806, SYNC_HnVn}
/* VESA: 1024x768 @ 75Hz */
{ 78750, 1024, 1040, 1136, 1312, 768, 769, 772, 800, SYNC_HPVP}
/* VESA: 1024x768 @ 85Hz */
{ 94500, 1024, 1072, 1168, 1376, 768, 769, 772, 808, SYNC_HPVP}
/* Matrox: Vesa_Monitor_@70Hz_(1152X864X8.Z1) */
{ 94200, 1152, 1184, 1280, 1472, 864, 865, 868, 914, SYNC_HPVP}
/* VESA: 1152x864 @ 75Hz */
{ 108000, 1152, 1216, 1344, 1600, 864, 865, 868, 900, SYNC_HPVP}
/* Matrox: Vesa_Monitor_@85Hz_(1152X864X8.Z1) */
{ 121500, 1152, 1216, 1344, 1568, 864, 865, 868, 911, SYNC_HPVP}
/* VESA: 1280x1024 @ 60Hz */
{ 108000, 1280, 1328, 1440, 1688, 1024, 1025, 1028, 1066, SYNC_HPVP}
/* VESA: 1280x1024 @ 75Hz */
{ 135000, 1280, 1296, 1440, 1688, 1024, 1025, 1028, 1066, SYNC_HPVP}
/* VESA: 1280x1024 @ 85Hz */
{ 157500, 1280, 1344, 1504, 1728, 1024, 1025, 1028, 1072, SYNC_HPVP}
/* VESA: 1600x1200 @ 60Hz */
{ 162000, 1600, 1664, 1856, 2160, 1200, 1201, 1204, 1250, SYNC_HPVP}
/* VESA: 1600x1200 @ 65Hz */
{ 175500, 1600, 1664, 1856, 2160, 1200, 1201, 1204, 1250, SYNC_HPVP}
/* VESA: 1600x1200 @ 70Hz */
{ 189000, 1600, 1664, 1856, 2160, 1200, 1201, 1204, 1250, SYNC_HPVP}
/* VESA: 1600x1200 @ 75Hz */
{ 202500, 1600, 1664, 1856, 2160, 1200, 1201, 1204, 1250, SYNC_HPVP}
/* Matrox: Vesa_Monitor_@80Hz_(1600X1200X8.Z1) */
{ 216000, 1600, 1680, 1872, 2160, 1200, 1201, 1204, 1250, SYNC_HPVP}
/* VESA: 1600x1200 @ 85Hz */
{ 229500, 1600, 1664, 1856, 2160, 1200, 1201, 1204, 1250, SYNC_HPVP}
/* VESA: 1792x1344 @ 60Hz */
{ 204750, 1792, 1920, 2120, 2448, 1344, 1345, 1348, 1394, SYNC_HnVP}
/* VESA: 1792x1344 @ 75Hz */
{ 261000, 1792, 1888, 2104, 2456, 1344, 1345, 1348, 1417, SYNC_HnVP}
/* VESA: 1856x1392 @ 60Hz */
{ 218250, 1856, 1952, 2176, 2528, 1392, 1393, 1396, 1439, SYNC_HnVP}
/* VESA: 1856x1392 @ 75Hz */
{ 288000, 1856, 1984, 2208, 2560, 1392, 1393, 1396, 1500, SYNC_HnVP}
/* VESA: 1920x1440 @ 60Hz */
{ 234000, 1920, 2048, 2256, 2600, 1440, 1441, 1444, 1500, SYNC_HnVP}
/* VESA: 1920x1440 @ 75Hz */
{ 297000, 1920, 2064, 2288, 2640, 1440, 1441, 1444, 1500, SYNC_HnVP}

Yes, he probably did, in fact.

That would be a neat trick.

Not all that tricky if the video card and monitor support the VESA Display Data Channel standard and the video card can get enough information from the monitor that way to let the host identify it.

I haven't bought the standards in question from VESA (they aren't cheap), so I don't know what sort of information you can get from plug-and-play monitors, but check out the VESA standards page.

It looks as if support for DDC, and at least some of the information you can get from it, may show up in XFree86 4.0; see this item in the XFree86 3.9.16 release notes.

Oh dear, you've gotten me started. As an occasional game author myself, I have some perspective on this (with lots of lessons learned the hard way from both sides), and it just happens that I've been thinking about this issue lately. Here are some things I believe Linux needs to improve its appeal to gamers and game developers.

Transparent Access to Full Screen Display Modes
SVGAlib has been an excellent tool for a long time, but it's starting to show its age, and it supports considerably fewer cards than the current release of XFree86. Further, it's silly to have to write a driver for the same card two or more times (once inside XFree86, once inside SVGAlib, etc.). I've read the work of The GGI Project, and I suggest interested techies do, too. There are no glaring flaws in the design (though it has odd warts here and there), and with work it could become an excellent foundation for high-performance graphics device control and configuration. SVGAlib and XFree86 could both be built on top of this structure. Thus, drivers would need to be written only once. I've love to see this move forward.

Unlike Windoze display modes (which all come out of a fixed table), Linux should be able to generate any resolution and scan rate the card can physically generate. Multi-monitor support would also be nice, but this is much harder (trust me on this one). Also, you should be able to launch a full-screen app from inside XFree86, and neither XFree nor the app should care (being able to switch back and forth would be nice, too). Ambitious souls may care to emulate BeOS's "Workspaces", where each virtual desktop can be a different resolution, scan rate, and pixel depth.

There also needs to be work done on supporting VESA DDC (Display Data Channel) which allows the system to identify the attached monitor and determine its scanning limits (thus alleviating the need for the dreaded mode table in XFree86config; just ask the monitor what it can do). We may also need to beat up on VESA to make its standards more readily available.

Expansion of OpenGL Efforts
OpenGL is the future of 3D gaming (just ask John Carmack). While Mesa is an excellent first step (and very complete), its performance is poor compared to OpenGL ICDs available for Windoze. Basically, we need to get the triangle counts up. Part of this can be done by optimizing Mesa. However, a significant portion of the rest has to be done by or in cooperation with the 3D card manufacturers.

A standard interface needs to be established between Mesa (or whatever OpenGL implementation ends up dominating) and the graphics cards. This will allow for Mesa and the hardware drivers to be evolved and optimized independently of each other. It also allows users to plug in any compliant card and expect it to work. This GL/hardware interface can be established at the driver level; the GGI people probably have suggestions on this.

Finally, everyone reading this article needs to beat up on the 3D card vendors to support Linux. Roughly half of all Quake servers are running on Linux. 3D card vendors live or die based on their Quake frame rates. Why should a server operator have to crash back into Windoze just to test out the latest RA/TF/CTF/LMCTF release? This alone is compelling enough reason for the 3D vendors to formally support Linux.

New Sound Architecture
OSS is functional (it works well for Quake and MikMod), but modern gaming requires much more. Sound has always been my weak point, so I don't have a lot of concrete ideas here. ALSA (Advanced Linux Sound Architecture) looks interesting, but I lack the knowledge to evaluate it properly.

Basically, the goals of the sound API need to include extremely low latency and low overhead. The system shouldn't be eaten alive just mixing and playing back sounds. Also, for applications that do buffer sounds ahead of time, there should be an event system built in such that the application can be informed when a particular sample or sample segment has started playing. This allows the client to synchonize other events (explosion visuals?) with the audio.

Networking
In my view, very little needs to be done here. Linux's socket API is one of the most reliable and complete implementations anywhere. There's no reason a game can't directly use network sockets.

Input Devices
Again, the keynote here is low latency and high sample rate. Most PS/2 mice will run at higher baud rates (if you're running Windoze at the moment, grab a copy of PS/2 Mouse Rate and see for yourself), so the mouse drivers should have the ability to tweak this.

I'm not as convinced that USB is important, but in order to get that to work, you better start beating up on Intel for the specs now. Intel's documentation department can be slow to respond (I'd use the term "glacial," but that conveys an unwarranted sense of haste). USB is a non-trivial beast. Getting all the device types, hubs, and hot-plugging issues down is going to take time.

Anyway, that's pretty much what's on my laundry list. I also have specific ideas on how some of this might get implemented. If I wasn't so darned employed, I'd probably be working on some aspect of this stuff.

Thanks for reading.

Schwab