VIA Releases 800 Pages of Documentation For Linux 131
billybob2 writes "VIA has published three programming guides that total 800 pages in length and cover their PadLock, CX700, and VX800/820 technologies. The VIA PadLock provides a random number generator, an advanced cryptography engine, and RSA algorithm computations. The VX800 chipset was VIA's first Integrated Graphics Processor, while the CX700 is a System Media Processor designed for the mobile market. This is another step in VIA's strategy to support the development of Free and Open Source drivers under Linux, which comes pre-installed on VIA products such as the Sylvania NetBook, HP Mini-Note, 15.4" gBook, gPC, CloudBook, Zonbu, and VIA OpenBook. Earlier this week, VIA hired Linux kernel developer and GPL-Violations.org founder Harald Welte to be VIA's liason to the Open Source community."
Re:linux? (Score:5, Informative)
Now Linux drivers can be written for the hardware. Just like TFS says.
Re:linux? (Score:5, Informative)
Well, as one of the other respondants pointed out, once the docs are out there, it can benefit any operating system, but the point is that VIA wants Linux, in particular (and the technologies like X that operate with the Linux kernel) to better support their products. I think of the three, the one that is most likely to be directly used by the Linux kernel dev is the crypto engine documentation. I think there are kernel-space crypto block device drivers (LUKS - at least, I think it's kernel space; I suppose it might be implemented in user-space) which could be accellerated by the padlock engine. In fact, I think the kernel already has some support for the padlock - whenever I boot my laptop, on which I have used LUKS to encrypt my /home partition, I get a warning that the padlock engine was not found (of course, because I have an Intel Core2 Duo, so don't have padlock).
Re:state of integrated graphics (Score:3, Informative)
and also the only one with fully accelerated 3d
That's just a mistake in TFS (Score:5, Informative)
Re:state of integrated graphics (Score:5, Informative)
It is cheaper and easier to not use ancient crap.
That all depends on who's buying the parts...
Your mindset considered, you'd better not look too closely into industrial control systems.... your head might explode.
Re:Just about time - now for the other solutions (Score:2, Informative)
p.s. also worth checking your X-Config too: here's my VIA video settings (tailored for TV-out...)
Section "Device"
Identifier "VIA Unichrome Pro II"
Driver "via"
Option "ActiveDevice" "TV"
Option "TVType" "PAL"
Option "TVOutput" "S-Video"
Option "TVDeflicker" "0"
#Option "TVDotCrawl" "true"
Option "EnableAGPDMA" "true"
Option "AccelMethod" "XAA" # XAA - safe, EXA - CRASH
#Option "EXANoComposite" "false" # disable exp. compositing
Option "DisplaySize" "400 300"
EndSection
Re:First Atheros and now this? (Score:3, Informative)
a ways back Creative was upset at someone who hacked up features into their Vista drivers which were purposefully absent (but present on their XP drivers). (...) Creative "lost" here even with closed source drivers - they'd have never stood a chance to screw over their customers if the drivers were open.
Creative licensed certain features for XP, that they didn't want to pay for in Vista. It wasn't that Creative was trying to force customers to buy more expensive cards, it was that Creative itself would have to pay an obscene sum to a third party for Vista support. Not getting permanent rights sounds like short-term cost saving on Creative's part but whoever cashed his bonus back in 2001 probably doesn't care. Whoever owned the rights probably knew they had Creative by the balls and got too greedy, so they did the only other thing they could which was to remove those features. Contractually Creative probably had to complain about the license violation. While it shows open drivers is good, but I don't think Creative was being evil here.
Re:First Atheros and now this? (Score:3, Informative)
http://en.wikipedia.org/wiki/Gallium_3D [wikipedia.org]
Re:state of integrated graphics (Score:2, Informative)
Not only that VIA made a smart move with its Nano design.
Realising that its C7 design, and by extension the Atom design, are not what people want, they moved towards an ultra-low voltage Core Solo design for their ITX motherboards. The Nano is strong enough to run Crysis with an 8600GT, all on miniITX hardware.
Not to mention the VX800 can output at 1900x1200, and can do hardware-playback of MPEG2, MPEG4 h.264 & ASF, along with a few other formats. This is all going to be documented for linux. So, HTPC builders, get ready! If VIA or a VIA partner is going to release a miniITX box based on the Nano, you bet your ass that would be the best MythTV platform ever, especially since nVidia is promoting MiniITX with PCIE x16, so you could even have a monster video card to boot.
Re:800 pages in length (Score:2, Informative)
A single core on a 3Ghz Core2 can match the performance of Padlock. I can't provide a link as the figures are unpublished but it's not particularly hard to work out how.
I don't suppose you could provide any numbers along with that claim? Because a non-padlock CPU matching the performance for AES-256 would be really useful sometimes.
For reference here are padlock numbers on a moderate Padlock equipped CPU:
cpu family : 6
model : 10
model name : VIA Esther processor 1200MHz
stepping : 9
cpu MHz : 1197.115
cache size : 128 KB
Using "openssl speed":
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-cbc 47592.92k 155506.46k 359193.00k 531778.27k 621832.68k
aes-256-ecb 58605.48k 213317.70k 578567.91k 1008950.60k 1287371.44k
And of course, as has already been mentioned, watts matter.
Re:How reliable is their random number generator? (Score:3, Informative)
According to them, it's quantum-effect based:
http://www.via.com.tw/en/initiatives/padlock/hardware.jsp [via.com.tw]
in short, it's a set of free running oscillators, where the exact frequency of each is affected by thermal noise. the instabilities generate an easy to detect "beating", turned into bits and accumulated in hardware registers.
there's very little 'source code for the chip' to read and validate; but there are several tools to statistically verify random distributions.
(this one looks nice: http://csrc.nist.gov/groups/ST/toolkit/rng/index.html [nist.gov]. i'll try to get some time to test it on my via mainboards...)