You are viewing libv

LIBV Intentionally Breaks Videodrivers [entries|archive|friends|userinfo]
Luc Verhaegen

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

FOSDEM, the best conference... In the world. [Feb. 5th, 2014|04:51 pm]
[Tags|, , , ]
[Current Location |Rumpelkammer]
[mood |gratefulgrateful]
[music |Underworld - Beaucoup Fish - Jumbo]

Now that my body is well on its road to recovery, it's time to talk about the great success that FOSDEM was, once again.

We had a really nice devroom and pretty good crowds, but the most amazing thing was the recordings and the livestream. The FOSDEM organizers really outdid themselves there.

After the initial announcement of the graphics devroom went out, Martin Peres contacted me and we talked about getting proper recordings from the DevRoom, and briefly looked into what this would end up costing if we were to buy the equipment for it. Our words were barely cold when the FOSDEM organizers announced what can only be seen as absolutely insane: they would try to provide for full recording of everything.

In the end, FOSDEM provided recording in 22 rooms. They had to get 22 mixing desks, 22 sets of microphones, 22 cameras, 44 laptops... This was apparently mostly rented, and apparently, surprise, surprise, there aren't many rental companies which have such an insane amount of kit available.

Apart from some minor issues (like a broken firewire cable in the wine devroom) things worked out amazingly. Only the FOSDEM guys could pull something this insane off. We had all our talks in the Graphics DevRoom streamed out live, with no issues at all.

I would like to thank all the speakers in the graphics devroom, but i particularly would like to thank Martin Peres, who took full control and responsibility of the video equipment. Then there's Marcus Meissner and Thiery Redding who willingly sat in the back of the devroom and handled the recordings themselves, directing the streams, for only meagre rations of water and cookies. Without people stepping up and doing their bit, a devroom like this would not be possible. And the same goes for the whole of FOSDEM.

At the end of the final talk, after i had talked about sunxi_kms, i tried to thank the FOSDEM organizers, and get the remaining audience to clap for them. But i mostly stood there and babbled, at a loss for words, because what the FOSDEM organizers had achieved with this insane goal is simply amazing. And thinking about it now still, i still get quite emotional...

How on earth did they manage to pull this off, on top of organizing the rest of FOSDEM, a FOSDEM which caters for something like 8000 people as it is... It's just not possible!

It's not as if these guys get paid for what they are doing, FOSDEM is a low budget organization, purely based on volunteers. The absolute core of the organization is just a handful of people who have very busy jobs. And yet, they have succeeded where any other organization would have failed. There's no politics or powerplay, there is no money or commerce. There is just the absolute drive to make FOSDEM the best event on the planet, by making small changes every year...

This was my 7th DevRoom this year, and if i can help it there will be another one next year. I am really proud that i am allowed to do my, comparatively little, part as well. Every sunday evening after FOSDEM, after we sit down in the restaurant with the remainders of the graphics devroom, i am physically broken, but i am also one of the happiest people on the planet...

Each year, no matter what happened in the year before, no matter what nasty open source politics or corporate nonsense took place over that year... Each year, the FOSDEM organizers prove that something amazing can happen if only people do their bit, if only people work towards the same selfless goal. Each year, FOSDEM reminds me of why i do what i do, and why i need to keep on doing it.

Thank you.
link2 comments|post comment

Last Preparations for Coreboot/Xorg DevRooms at FOSDEM. [Feb. 4th, 2010|10:21 am]
[Tags|, , ]
[Current Location |couch]
[mood |tiredtired]
[music |The noise of a crappy high speed via mini-itx fan.]

In about 30h I will be on the ICE to Brussels to FOSDEM, to have 2 DevRooms there.

The Sportsbag with kit has been packed. The meeting at the customary restaurant tomorrow evening has been pretty much set up. Both my talks should be ready, and just need some studying. And I am now making the posters with the schedules and the fliers (used for possible status changes and directions) for the two devrooms so that they can be printed out later today.

The schedule for the Coreboot DevRoom (on saturday) is unchanged since my last post:

* 13:00 : Peter Stuge - coreboot introduction.
* 14:00 : Peter Stuge - coreboot and PC technical details.
* 15:00 : Rudolf Marek - ACPI and Suspend/Resume under coreboot.
* 16:00 : Rudolf Marek - coreboot board porting.
* 17:00 : Carl-Daniel Hailfinger - Flashrom.
* 18:00 : Luc Verhaegen - Flash Enable BIOS Reverse Engineering.

All seems well, and it seems that we will have everything filmed nicely too!

The schedule for the Xorg DevRoom (on sunday) has seen one last minute change with the addition of Nicolai Haehnle's talk:

* 12.00: Nicolai Hähnle : Towards GLSL in the r300 Gallium driver
* 13.00: Daniel Stone : Polishing X11 and making it shiny.
* 14.00: Luc Verhaegen : The free software desktop’s graphics driver stack.
* 15.00: Jerome Glisse : GPU Userspace - kernel interface & Radeon kernel modesetting status.
* 16.00: Mikhail Gusarov : X on e-Paper.

This addition was very last minute, and did not make the FOSDEM folder. Nicolai was quite lucky as the FOSDEM organisers had already assigned the DevRoom to the openMoko project in the morning, which luckily left a single slot free for Nicolai.

I've finished my slides for my own talk in the X.org devRoom, and it promises to be an interesting one, albeit controversial for some.

It examines some of what we can tell a few years down the road from the modular tree, and goes over the real needs. Then it explains the unification of graphics driver stacks, how to build it for the unichrome driver, and what infrastructural changes it could use.

But before i go into details i will have a small in room survey (Which will probably become a more widespread survey online). One of the questions i will ask is: "For those using, or those who have used, the nvidia or ati closed source drivers: how would you like it if nvidia or ATI told you that you needed the very latest upstream kernel, X, and mesa to be able to run the latest catalyst or nvidia driver, especially when you might need this version for its new hardware support or for bugfixes?"

(and urgh... the msi fuzzy cn700t motherboard i was using as a mailserver just died on me, even the port80 card says that no bios code is being run. Now i stuck in another cn700 board, and it has one of those really noisy fans :()
linkpost comment

FOSDEM: Coreboot and X.org Schedules. [Jan. 22nd, 2010|02:23 am]
[Tags|, , ]
[Current Location |couch]
[mood |mixed.]
[music |Fingathing - SuperHero Music - SuperHero Music]

coreboot DevRoom

This year, at FOSDEM, there is a coreboot DevRoom, and for the hardware-lover, there are some really interesting talks there. When putting together the final schedule, I actually had to spend some time on containing people's enthusiasm and limiting their ideas to something feasible for FOSDEM. A rather good sign, and i am sure that many people will enjoy the truly interesting and juicily in-depth talks there.

Here is a quick copy of the saturday afternoon schedule:
* 13:00 : Peter Stuge - coreboot introduction.
* 14:00 : Peter Stuge - coreboot and PC technical details.
* 15:00 : Rudolf Marek - ACPI and Suspend/Resume under coreboot.
* 16:00 : Rudolf Marek - coreboot board porting.
* 17:00 : Carl-Daniel Hailfinger - Flashrom.
* 18:00 : Luc Verhaegen - Flash Enable BIOS Reverse Engineering.

So yeah, i have a talk at 18:00 which promises to be fun.

Basically, for flashrom, we sometimes need to find out what write protection certain motherboards implement, so we can disable that from within flashrom. This usually means that someone (usually Michael Karcher or me) has to go and disassemble the BIOS to find out which GPIO line needs to be toggled.

For a single board, this is usually not a hard task (and actually fun), but the overal amount of work in flashrom is sizable, and the two of us are not available 24/7 to do this for every user in need. So this talk is meant to alleviate that.

I just wrote the slides for it, and while i might alter the notes and twiddle it a bit still in the next two weeks, it should be pretty much finished.

The structure of the talk is the following:
* quick overview of how flashes are usually wired up on motherboards.
* quick overview of how to handle Award, ASUS, AMI and phoenix BIOSes.
* example of disassembly of a BIOS.

The BIOS that is being disassembled is an especially crafted one, with an award style flash enable for a fictitious board. It's mostly filled with 0xFF, apart from the flash enable itself. And the talk itself is pretty accessible, you do not have to know much of assembly or hardware to be able to participate.

If you are visiting the talk, and you want to join in, then you might already want to download the image, and make sure that you have hexdump and ndisasm installed (as there are about 4000 others trying to use the wireless at FOSDEM).

It promises to be a blast!

X.org DevRoom

On sunday there is of course the X.org DevRoom, for which the schedule is also online.

It seems to be a tradition that I have to go and beg people to talk at truly great event like FOSDEM.

Last year, we had 7 talks in the brochure, while there was room for 13, and we eventually had 9 talks. All these talks were hugely popular, with almost full capacity usage most of the time, but the actual talk coverage itself left much to be desired.

This year I decided to split the usual two day X.org DevRoom into coreboot (saturday afternoon) and X.org (sunday), so that the X.org schedule could be tighter and more exciting.

Here is the result;
* 10.00: ...
* 11.00: ...
* 12.00: ...
* 13.00: Daniel Stone : Polishing X11 and making it shiny.
* 14.00: Luc Verhaegen : The free software desktop’s graphics driver stack.
* 15.00: Jerome Glisse : GPU Userspace - kernel interface & Radeon kernel modesetting status.
* 16.00: Mikhail Gusarov : X on e-Paper.

I, and a lot of fosdem visitors with me, thank Daniel, Jerome and Mikhail for their commitment. These talks seem very interesting and will no doubt draw in a lot of visitors and carry out the good name of X.org.

It does make one think. There seems to be a direct and inverse relationship between the size and status of a free software project, and the willingness of its members to go and promote this project on the biggest free software event on that continent that holds the majority of its current developers and the largest potential of future contributors.

In any case, I have been communicated that, as there are many very worthwhile and also very willing projects who get denied a DevRoom each year, a project with such a poor showing will not be given another DevRoom.

While I start putting together the slides for my X.org talk, I can only concede.
link2 comments|post comment

Coreboot and Xorg DevRooms at FOSDEM! [Dec. 2nd, 2009|04:27 am]
[Tags|, , ]
[Current Location |couch]
[mood |jubilantjubilant]
[music |Compuphonic & Kolombo - Antimatter (unreleased edit)]

Yeah, you read that correctly, there will be two close to the metal DevRooms at FOSDEM this year (or next year, Mr. Daenzer :))

FOSDEM 2010 runs on the 6th and 7th of February and in the AW building in room AW.124 there will be some really interesting things happening :)

On Saturday the 6th, the first coreboot DevRoom will be held there. It's still early days, but several key developers will be there, and we will be showing off coreboot, flashrom and will be presenting some really cool stuff. You can track the talks list on the coreboot wiki.

On Sunday, we will have the X.org DevRoom there, for the fifth time already. This DevRoom has really been one of the best filled and most interesting ones for the past few years, with highly in-depth and technical talks, and we of course will provide the same this year :) X.org tracking page is on the X.org wiki.

As per usual, we will try to get people together on friday evening and visit that one restaurant on the grand place that we tend to visit each year (whose name i can never remember :)). And if enough people give me a heads up, i will try to reserve a big table at the excellent Mirabelle again for saturday.

As for people who are interested in speaking at one of the DevRooms, check the page of the individual projects for more details and do not hesitate to mail me or Egbert.
linkpost comment

Hardware MPEG2 Slice decoding added to unichrome driver. [Nov. 4th, 2009|10:24 pm]
[Tags|, , , , ]
[Current Location |couch]
[music |The Dust Brothers - Medula Oblongata]

I just pushed out code which adds MPEG2 slice decoding to my graphics driver. It is based on XvMC, but unlike "standard" XvMC implementations, it sends MPEG slices over to the graphics driver over the X protocol.

The base idea is the following: The MPEG engine gets MPEG slices, and outputs to a buffer. This buffer needs to then be displayed by the overlay engine. So, we need to spend most of our time managing the communication and syncing of those engines. We already have the other video engines implemented nicely, so, why not stick the MPEG code next to that and have a nice and clean implementation?

The XvMC protocol, X-wise, is mostly about telling the driver that the MPEG hardware is in use, and subsequently claiming buffers in the framebuffer, managed by the X driver. Everything else is expected to happen in the client library. For what reason, i do not know, but part of it could be that, this way, X is not seen to eat any CPU cycles. In any case, this makes it a very weird protocol, with things spread all over the stack.

Things were made worse with the advent of the XvMC wrapper. Instead of expanding the XvMC protocol slightly to provide the name of the XvMC client library to be loaded, DRI is abused for this purpose. So... a pointless hard dependency on DRI is added, and now, no working DRI means no working XvMC... Curious. Makes the pointless dependency on Shm look harmless.

So what i did now is send all the data over the X protocol, over a tiny X extenstion, so that it could be fed into the hardware and synced inside the X driver. An XvPutImage with a longword buffer containing the mpeg buffer id then makes sure that everything gets displayed correctly. And while the overlay is being set up, the mpeg engine can finish its work, and at the very last minute, the overlay code waits for the mpeg engine to finish, and then the overlay gets told to display the new image.

Other XvMC implementations went and completely reimplemented the overlay in the client library, and even involved 2d acceleration to be able to send mpeg slices to the hw a bit faster. A syncing nightmare. Another advantage is that my implementation can implement the newer mpeg2 engines in just a few hundred highly hardware specific lines.

Of course, sending this data over the X protocol in tiny bits does incur some more cpu cycles, and i also am not feeding mpeg data into the hardware over the command buffers. Because of this, my code uses about 30-35% for a normal DVD (write a comment if you guessed which :)) on a VIA C3 Samuel2 (yes, half speed FPU, not quite PPro compatible) at 600Mhz, while openchrome uses 20-25%, roughly 2/3rds. But the performance of my code is still very good, good enough to not bother with speeding things up just yet.

As usual, it is easy to get this new code. It builds and runs against all Xorg versions that are common, and the debian package build system has also been updated for the xvmc code.

For xine there is one caveat, due to the horrible implementation of video_out_xxmc. We need to fool xine into thinking that we do support subpictures (we don't as it the xxmc way of implementing things didn't even get close to how the hardware implemented it). For that, the following option needs to be set:

Option "XvMCBrokenXine" "True"

in the device section of xorg.conf.

Enjoy!
link3 comments|post comment

X@FOSDEM2008: We have a devroom! [Nov. 28th, 2007|07:12 pm]
[Tags|]
[Current Location |office]
[music |Elmer Bernstein - Theme from "The Great Escape"]

Yup, we have one, and a bigger one too, so we can honestly state that we are bigger than ever!

The wiki page for this is set up here.

We will hopefully have a hothouse beforehand, but of course, this is just an intention so far.

What i would like to know ASAP is the following:

* First: anyone interested in speaking at the devroom? I think i can poke people for at least more than half of the 11 slots already, but if you do want to have a talk at the Xorg Devroom at FOSDEM2008, get in touch ASAP. The deadline for speakers for Xorg is 31st january 2008.

* Secondly, i would like to hear from X developers whether they are interested in coming to the hothouse on friday, and whether they would also come on thursday. If you do not know what a hothouse is please, visit the above wikipage again.

So... 23 and 24 of February 2008, in brussels, at the ULB Solbosch campus. Xorg DevRoom. Be there.
linkpost comment

Keith plugged on LWN. [Feb. 1st, 2007|11:02 am]
[Tags|, ]
[mood |annoyedannoyed]
[music |Nina Simone - Sinnerman (Felix The Housecat remix)]

LWN just made it's LCA X coverage public.

Randr, randr, randr.

Once again, the importance of the split between fb<->crtc<->output is underlined. The main difference between this and the previous randr is the split of crtcs and outputs.

It is this exact split that keithp said was "Wrong", and a general modesetting system was said to be "impossible". Yup, at EXDC, during an intel paid lunch, when Waldo was writing down what intel could do for X, keith said that I, on all my views and ideas about modesetting, was completely wrong. He completely torpedoed me then.

And now he's been acting as if he pretty much came up with the split himself.

In the comments section at LWN, some people have picked up on this story. Here are some replies:

i3839: I don't _feel_ as if my ideas and code are used without being given credit. My ideas and code are out there, very much set in stone. And where is the credit? This is not a feeling, this is a fact. And Keith/intel aren't just trying, they are quite aggressively doing.

bronson: What do you believe in? Someone who can point to a long history of code and some talks? Or someone who works for a well known monopolist, telling you that that monopolist is great, and, suddenly, out of the blue, comes with the solution to world hunger, especially on things bought from that monopolist?

Yes, KGI is just another example of how Keith works. And it seems that there are plenty more things in X's history that have been unjustifiedly torpedoed by Keith. Most are hidden by history, as history is a very mouldable thing, and always written by the victorious party.

The history here is quite clear, and quite well documented. But not many people will learn about it, they will only see that other history.

The one thing that isn't proven in the current story, is what keith said at that lunch at EXDC.

It'll be hard to get a solid confirmation on that, as Keith himself is clearly not willing to admit to it. There were only six people there, one of which (Waldo Bastian) is a direct colleague, Alan Hourihane is working for a company that depends on intels contracts, one is Daniel Stone (need i say more?), who, quite unsurprisingly, claims to not remember what was said. The last person there is Egbert Eich, a long time Xorg Board member, who used to work with Keith at SuSE around the millenium, so the chance of getting confirmation from that end is slim too.

This is exactly how X works. Politics and money. Code, insights and ideas only matter if they come from the right parties.

In this story I've been compared to xfree86's David Dawes a few times. This is another story where Keith was heavily involved, and where history doesn't exactly favour David. I was not in any way following this row at the time, i even took unichrome development outside of this completely (something still frowned at by current X.org politicians), but I'm left wondering now.

What really did happen in the run up to Dawes adjusting the license? Who pushed him that far?

I'm sure that history will not be that clear on what really happened.
link12 comments|post comment

navigation
[ viewing | most recent entries ]