XvMC Comes To xf86-video-unichrome Driver

[phoronix]

Phoronix: XvMC Comes To xf86-video-unichrome Driver

Earlier this year Luc Verhaegen, one of the key contributors to the RadeonHD graphics driver, was laid off from Novell after a round of cutbacks at their German facility. While remaining unemployed, Luc has contributed to the CoreBoot project with ATI graphics card flashing support and native VGA text mode support, among other work...

http://www.phoronix.com/vr.php?view=NzY3NQ

[DanL]

It's nice that Phoronix keeps us up to date on our FOSS heroes. I hope Luc finds employment soon. I heard there's an opening at ATI...

[droidhacker]

So...
He implemented XvMC in a manner that is 1) incompatible with existing assumptions about the implementation of XvMC, and 2) is limited to a driver for hardware that hardly anyone uses.

What exactly does this accomplish?

[libv]

So...
He implemented XvMC in a manner that is 1) incompatible with existing assumptions about the implementation of XvMC, and 2) is limited to a driver for hardware that hardly anyone uses.

What exactly does this accomplish?

It is compatible with existing XvMC clients. I just question assumptions everywhere and usually find where they are wrong, it's how i am. Also; of course it is limited to this driver, that's how all XvMC drivers are.

[duby229]

It is compatible with existing XvMC clients. I just question assumptions everywhere and usually find where they are wrong, it's how i am. Also; of course it is limited to this driver, that's how all XvMC drivers are.

I have to agree with him though. Why implement it in Unichrome? Radeon would have given you a much larger user base for testing, and would have been immediately useful to a whole lot more people.

[bridgman]

I can probably answer that one... info is available to program the video decode hardware on the Via chip but not on our chip.

[libv]

I have to agree with him though. Why implement it in Unichrome? Radeon would have given you a much larger user base for testing, and would have been immediately useful to a whole lot more people.

???

I implemented unichrome MPEG2 hardware slice decoding acceleration. I wrote a tiny X protocol to feed the mpeg data into the part of the driver that feeds that data into the hardware. The tiny X protocol was not the goal, it was a tool to function as a back-end for the unichrome XvMC client library, and it will not grow beyond this driver.

Why you think this involves other drivers is beyond me.

[libv]

I can probably answer that one... info is available to program the video decode hardware on the Via chip but not on our chip.

Eh? I did not care about implementing just any XvMC support.

But more on that next week on my blog, right now i am waiting for the masses to stop roaring about this important new development.

[duby229]

???

I implemented unichrome MPEG2 hardware slice decoding acceleration. I wrote a tiny X protocol to feed the mpeg data into the part of the driver that feeds that data into the hardware. The tiny X protocol was not the goal, it was a tool to function as a back-end for the unichrome XvMC client library, and it will not grow beyond this driver.

Why you think this involves other drivers is beyond me.

Honestly I'm not a programmer. I really dont know how those things work. Being a radeon user though, and your experience with ATi hardware, and clearly your experience with XvMC would seem like a logical choice.

I guess I could more appropriately phrase my question as "Why implement XvMC in unichrome when it would serve a whole lot more people to implement it in radeon?"

[duby229]

I can probably answer that one... info is available to program the video decode hardware on the Via chip but not on our chip.

Soooo uuuuhhhhhh,,,,

Hows that.... ummmmm...... documentation coming?

[libv]

Honestly I'm not a programmer. I really dont know how those things work. Being a radeon user though, and your experience with ATi hardware, and clearly your experience with XvMC would seem like a logical choice.

I guess I could more appropriately phrase my question as "Why implement XvMC in unichrome when it would serve a whole lot more people to implement it in radeon?"

So other hardware should not be cared for?

I started out with unichrome in 2003. I own a very comprehensive set of hardware today. I developed the fundamental concepts of modesetting today on unichrome. And without my work on unichrome, you would not even have a free r500 and up driver today (because then ATI would have gotten away with trying to kill radeonhd before the release), you would be stuck with fglrx and some spare-time attempt at a free driver that was struggling due to a lack of resources and a lack of information.

But really, what does any of this have to do with this topic?

[libv]

Soooo uuuuhhhhhh,,,,

Hows that.... ummmmm...... documentation coming?

It's still being delayed by me having implemented real modesetting more than two years ago :)

[duby229]

So other hardware should not be cared for?

I started out with unichrome in 2003. I own a very comprehensive set of hardware today. I developed the fundamental concepts of modesetting today on unichrome. And without my work on unichrome, you would not even have a free r500 and up driver today (because then ATI would have gotten away with trying to kill radeonhd before the release), you would be stuck with fglrx and some spare-time attempt at a free driver that was struggling due to a lack of resources and a lack of information.

But really, what does any of this have to do with this topic?

The Topic is XvMC comes to unichrome, which is exactly what we are discussing isnt it? If that isnt on topic then I dont know what is.

I'm definately not saying that unichrome shouldnt be cared for too. I think your work is great. I'm glad to see the state of video acceleration improving in linux even if it is for some barely useful video card that almost nobody uses....

[duby229]

It's still being delayed by me having implemented real modesetting more than two years ago :)

The unichrome driver seems to work great. I'm not sure what you mean by "real modesetting" though. Does Via use something like AtomBIOS too?

[libv]

The Topic is XvMC comes to unichrome, which is exactly what we are discussing isnt it? If that isnt on topic then I dont know what is.

I'm definately not saying that unichrome shouldnt be cared for too. I think your work is great. I'm glad to see the state of video acceleration improving in linux even if it is for some barely useful video card that almost nobody uses....

Well...

Intel is the big monopolist that owns a big team of developers, most of which just care about their own individual stature or having fun, and they are steering the linux desktop straight into the abyss.
Nvidia is the big closed source firm that might vanish at any moment, and that will never open up.
AMD never really managed to get ATI under control, ATI current controls AMD. Have you seen any free docs on real hardware stuff recently?

What is left after those three?

VIA. Stupid .tw people (it's a cultural thing) who never really have understood free software. At least they are not evil, and might actually be open to change for the better of free software.

[libv]

The unichrome driver seems to work great. I'm not sure what you mean by "real modesetting" though. Does Via use something like AtomBIOS too?

Almost... Just pointing out that every delay in bridgman providing documentation, or not delivering at all, used to be blamed on me writing real drivers and the SUSE devs asking questions. Questions which never really got answers from ATI anyway, and most of those answers were needed for a "full" atombios based modesetting driver too.

[Kano]

I tested that driver on a problematic via laptop. It only runs with vesa currently. Not even switching from unichrome to vesa worked. No edid was used, here are the EE/WW lines:

(WW) VT3371 support is experimental.
(EE) UNICHROME(0): Unknown Card-Ids (1509|1E30), report this to unichrome-devel@lists.sf.net ASAP
(WW) UNICHROME(0): ViaScratchGet: It is possible that PanelSize wasn't initialised properly
(EE) UNICHROME(0): No active output found.
(EE) UNICHROME(0): No outputs possible.
(EE) Screen(s) found, but none have a usable configuration.

[libv]

I tested that driver on a problematic via laptop. It only runs with vesa currently. Not even switching from unichrome to vesa worked. No edid was used, here are the EE/WW lines:

(WW) VT3371 support is experimental.
(EE) UNICHROME(0): Unknown Card-Ids (1509|1E30), report this to unichrome-devel@lists.sf.net ASAP
(WW) UNICHROME(0): ViaScratchGet: It is possible that PanelSize wasn't initialised properly
(EE) UNICHROME(0): No active output found.
(EE) UNICHROME(0): No outputs possible.
(EE) Screen(s) found, but none have a usable configuration.

Wow! A kontron device with workable pciids! This must be like a first, usually embedded vendors forgo such niceties.

Can you get onto the unichrome-devel mailinglist, and provide more info on this board (at least a board model name).

Don't expect any miracles just yet though, while i have added basic modesetting support for all unichrome devices just now, i still need to go and add panel/dvi/tv/hdmi support for the full range.

[Kano]

I can not test it when i want. It was a Kanotix user laptop called Belinea c.book VA250G. Had only ssh access.

[libv]

I can not test it when i want. It was a Kanotix user laptop called Belinea c.book VA250G. Had only ssh access.

Ah, ok, will add this model to the id list.