planet.freedesktop.org
 |
|
| February 09, 2010 | |
 |
|
|
| February 08, 2010 | |
|
GEOMPROPERTY GS_INPUT_PRIMITIVE TRIANGLESPROPERTY GS_OUTPUT_PRIMITIVE TRIANGLE_STRIPDCL IN[][0], POSITIONDCL IN[][1], COLOR
|
|
| February 07, 2010 | |
|
Me: "I think I'm done buying computers that I can't run my own code on."
Friend: "Just think of the iPad as being a pile of books. You can't run your code on those either."
Me: "Thinking of a computer as being a pile of books is like thinking of a guitar as being Abbey Road by the Beatles."
|
|
| February 04, 2010 | |
|
I’m glad to announce the first release of our fully managed Theora audio / video decoder implementation for the Silverlight platform! The Highgate media suite will bring installation-free support for HTML5 streaming video to an additional ~40% of web users overnight.
So, a few drinks will be in order to celebrate the release at the FOSDEM beer event, Friday — drop by! And of course, I’d like to invite anyone excited about making open codecs a first class citizen of the Silverlight / Moonlight ecosystem to visit the Mono dev room over the weekend for source code and some frivolous demos between sessions.
We’ll be releasing a high-performance decoder for Theora video / Ogg Vorbis audio streams that plugs into the Silverlight 3 streaming media abstraction, as well as a reference front-end player interface and JavaScript bridge layer providing basic compatibility with standard HTML5 media tags, adding support for the standard to Internet Explorer and extending the capabilities of WebKit-based browsers like Safari and Epiphany. A cunning plan, one might say!
I'm happy to go to Brussels again this year: it's been a long time since I didn't eat some really good waffles! Of course, I had to pretend I would do something useful there, so I'm participating in two talks
, both in the distributions devroom:
I'm also eager to have some insightful discussions with the great people that will come to FOSDEM. The hallway meetings have always been productive there!
GNOME
GNOME will have some strong presence again this year. There's the GNOME devroom on Saturday, that will become CrossDesktop devroom on Sunday, and during the whole week-end, we'll have a booth. If you want to help, that's definitely the place where you should go: we need volunteers to run the booth (see Lionel's mail for more details).
The booth should look great again, thanks to the event box, lovely stickers (they'll be free again!) and, hopefully, t-shirts (we're unsure they'll be ready in time, but let's be optimistic ;-)). On Saturday, you'll also find there some information about what is becoming a tradition: the GNOME Beer Event that will occur on Saturday evening.
Oh, apparently, I was volunteered to organize the GNOME group photo on Saturday, at 15:30. So make sure to be around the devroom at that time!
openSUSE
There will also be a good number of openSUSE people, with the usual booth (looking for some openSUSE DVD or sticker? You'll find them there!). This year, there's no openSUSE devroom because there's one big distributions devroom instead; I believe it's a good thing, though: it should help get more collaboration happen, and it's also a nice opportunity to steal good ideas ;-)
I'm happy that most of the boosters team will also attend; I heard it's a great group of people to hang out with!
|
|
| February 03, 2010 | |
|
|
|
| February 02, 2010 | |
|
Went down to London yesterday for a meeting and I used the opportunity to visit the scandinavian deli and grocery store there. Turned out to be pretty nice, with a decent selection of food. I stocked up on Swedish liquorice, Norwegian lompe, Danish red hotdog sausages and a Norwegian brown cheese.
In other words I am well set for another week of scaring Abigail with Scandinavian food 
|
|
| February 01, 2010 | |
|
I’ve just pushed initial evergreen (Radeon HD5xxx) modesetting support to xf86-video-ati. There are still some issues to be sorted out with multi-head, and displayport doesn’t quite work yet, but these will be worked out soon. Initial evergreen KMS modesetting support is also just about done and will be released soon. Acceleration is not available yet.
UPDATE: KMS support for evergreen is now working. You can grab the patches here. Dave should have them merged into the drm-radeon-testing branch soon.
The Bluetooth DUN package has been well received, but was hardly a profound programming endeavour. So, I’ve been trying to find suitable inspiration for a more substantial project. This morning, someone made a comment on the Bluetooth DUN page that there’s no way to tell if the phone has a tethered data connection or not - and he’s right: there’s no visual feedback on the phone, unlike Nokia’s Symbian devices or, I imagine, many other phones in the world. With that as a motivation, I decided to try and write a status indicator for tethering.
My first decision was language, and I went with Python as I’ve wanted to use it more and I know how laborious it would be to write this kind of utility in C. I then had to dig around to find out how to write a status area plugin in Python, and luckily there is a way, and it’sfairly well documented.
The biggest source of confusion is that the get_dbus_connection method isn’t exposed in the Python bindings. So, after that took *way* too much time to work out, I had to try and achieve the same thing with direct DBus calls (get a private connection that doesn’t kill the app if it dies), which I reckon I’ve got right.
Once you’ve got the basic stuff sorted out, it becomes really easy to iterate and test - you replace the python file and move .desktop file in and out of a specific directory and Hildon will reload it. Debugging was a real pain because the phone components that I’m talking too don’t exist inside the scratchbox dev environment - so I had to play a trial and error game on the N900 itself, where my only feedback was the icon failing to appear - what fun.
The next challenge was investigating what DBus interfaces to use to find the necessary information. The most important one is com.nokia.csd.GPRS. It’s not documented anywhere, but it’s fortunately introspectable and has obviously named methods and signals, so I was able to establish when a connection is made, suspended or disconnected.
Unfortunately, you see the same set of signals whether the connection is made by the phone itself or a tethered client, so then I had to find a way to detect if the phone was using the connection. I eventually found a way by using com.nokia.icd and com.nokia.icd2 - the first is undocumented and unintrospectable while the second is actually documented. For com.nokia.icd, I was able to use dbus-monitor to find a useful status signal and the get_ipinfo() method I needed had been explored by others. So, now I can avoid false positives from phone initiated connections.
There is one problem that remains, however: It’s possible to tether through the phone at the same time that the phone is using the connection for itself - this is apparently not as amazing as it sounds; all my old phones could do it. In this case, there appears to be no way to notice the tethered connection, so the monitor will not report it. At the moment, I’ve got no good ideas for doing this cleanly - I might be able to poke sysfs or look for pnatd processes, but neither is particularly attractive. But it’s not that common a case, so I consider the program useful before this gets solved.
And what does the program actually do? It shows an icon in the status area that reflects the connection state: disabled, attached, or suspended. I actually think that showing an icon when there’s no connection is a bad use of real eastate, so I’m going to take that out of the next release, but it’s there for now and helpful for confirming that the plugin actually started.
If you’re interested, you can grab it from extras-devel.
Enjoy!
|
|
| January 29, 2010 | |
|
Wow it’s been awhile. Life in the land of Linux graphics has been exciting recently, and there have been a few interesting developments on the Linux PCI front as well.
The Linux graphics stack has really been maturing recently. The Intel and radeon KMS drivers are seeing a lot of bug fixing, and nouveau is getting into shape as well. I think the Intel driver is in better shape than the userland driver ever was at this point (though that’s not to say it’s without defects; our serious bug count is still way too high for my liking). It supports more hardware and features, including power saving, DisplayPort, new hardware, advanced rendering APIs, than ever, and has been shipping in Linux distros for quite awhile now.
We recently finished off the page flipping support, and landed it upstream (it’ll be part of 2.6.33). We also landed a new, core, buffer execution interface (creatively named execbuf2), that allows for more flexibility in the way we submit our command buffers. Specifically, it allows us to control whether a given buffer needs to be mapped with a fence register for operations performed by the commands in its parent execution buffer. This allows our command buffers to be larger, since we won’t exhaust our fence registers prematurely by mapping all objects unconditionally, and allows us to enable tiled texture rendering on pre-965 chips, which can improve performance significantly for some types of rendering.
To support the page flipping work, I had to extend the DRI2 protocol a bit to include support for a SwapBuffers request. While I was at it, I added support for the SGI_video_sync and OML_sync_control extensions, which meant adding support for a few more requests. The SGI_video_sync addition was an important one, since its absence was a regression relative to DRI1. All this new protocol meant new Mesa and X server code, new DRI2 interfaces between the server and DDX drivers, and a bunch of testing and reworking of the interfaces as I figured things out.
All these new features are landed now, and should be a part of Linux 2.6.33, Mesa 7.8, X server 1.9 and xf86-video-intel 2.11. See CompositeSwap for an overview of the features and how they’re implemented. With that out of the way I’ve been able to think more about how compositors and clients should interact, so I came up with CNP. It’s not implemented yet, since I’m still gathering feedback on it, but my hope is that it will help us reduce memory consumption and partial frames in composited environments, as well as address some of the undefined behavior of current GLX calls when drawables are redirected.
Finally, after some discussions with toolkit and compositor developers, I worked with Kristian and Ian to come up with the INTEL_swap_event GLX extension (note it’s definitely possible to implement this on non-Intel as well, but only Intel has support at the moment). This extension allows GLX clients to receive X events when previously queued buffer swaps complete. So rather than making another swap call before the previous one has completed, clients with mainloops can simply poll their X event queue and do other work if their last swap isn’t done yet, rather than wasting time blocked in the server or queuing another swap and getting too far ahead of the display.
One side effect of the new DRI2 code is that glXSwapBuffers calls are now totally asynchronous. Previous versions of DRI1 and DRI2 would either block waiting for vblank, or only return after the blit to implement the swap had completed. With the new code, a DRI2SwapBuffers protocol request ends up in the X server, where it’s scheduled by the DDX driver to occur at some later time (though in some cases it will happen immediately, e.g. if the drawable is offscreen). This leaves more time for clients to do other work while their swap occurs; the INTEL_swap_event extension can help clients take advantage of this extra CPU time.
Some optimizations are present in the new code as well. For instance, if the drawable is the same size as the current root window pixmap and there’s no clipping to worry about, the DDX driver can queue a page flip instead. This saves a tremendous amount of memory bandwidth, and so can really increase performance, especially on high resolution and/or bandwidth starved configurations (e.g. most integrated and embedded graphics platforms). Similarly, if a simple back to front copy is requested for a window, if the back and front pixmaps are the same size (i.e. the window manager hasn’t reparented the front window to accommodate decorations and the like), the DDX can simply exchange the backing pixmap object pointers rather than blit. Again this is important on low memory bandwidth platforms (though note this code is currently disabled due to lack of testing; however it’s trivial to enable once I have some test cases).
With our Core i7 parts launched, I can talk about some of the hardware feature work we’ve been doing. Zhenyu has been doing most of the bringup and hardware support work for this platform, but I’ve been busy with one of the more interesting hardware features in the Core i7-6xx series, called Intelligent Power Sharing (IPS). Core i7-6xx and 7xx chips are MCP (multi-chip packages); both the CPU and GPU/MCH are in the same physical processor package, but not on the same die. This means they share a thermal and power design domain. In many cases, only one of the components will be very busy, and thus generating much heat or drawing much power, and it would be a waste to let any extra thermal or power headroom go unused. IPS allows one component to use more than its share of power or thermal budget so long as the other component is idle enough to allow it. One of the key parts of this technology is so-called “graphics turbo", in other words the capability of the GPU to exceed its default frequency (and therefore thermal and power budget) when possible. I posted support for this at around launch time (latest patch here), and hope to be able to post the full IPS driver soon, since the potential graphics performance upside is fairly large (still collecting measurements but I’m hoping for something around 15% or maybe even a little higher). The code also allows the GPU to downclock when idle, saving power. The CPU already has its own opportunistic turbo mode which is very effective, but there may be cases where giving it extra power will be helpful (though I’ve yet to find a benchmark, again I’m still testing).
A recent thread highlighted an interesting design choice in Linux. All platforms supporting PCI (indeed pretty much every platform, PCI or no), splits its address space into multiple regions, allowing for memory mapped I/O (MMIO) from the CPU to different devices. Discovering which ranges belong to which devices is done in a number of different ways, from hard coded offsets (as is found on many embedded platforms), to firmware descriptor tables (as found in OpenFirmware or ACPI), to physically reading MMIO routing information from CPU host bridges down through the hierarchy.
There’s a drive in Linux to support the last option. After all, Linux is the operating system driving your hardware, it should do everything itself, right? Well, that’s where we get into trouble. Linux usually runs on platforms designed for Windows (either specifically for Windows or for Windows in addition to Linux). Windows generally uses the second option to make it easier to port to new platforms. For better or for worse (usually the latter) BIOS writers for new platforms generally consider their work done when Windows boots on their new platform and the Windows device manager doesn’t have any dreaded “yellow bang"s next to devices in the device tree. This usually means the ACPI tables used to describe MMIO layout need to be fairly accurate, or Windows may map a device into a location occupied by another or by a host bridge range with decode priority, causing hangs, corruption or the dreaded “yellow bang".
In October of last year, for arguably good reason, we tried to take Linux down the last path. Yinghai Lu added support for reading root bus resource ranges directly from the host bridge on Intel systems. The thought was that we’d be insulated from firmware bugs this way, and have a more accurate view of the system in general. Unfortunately, due to the above, bridge vendors like Intel have no reason to fully document all the decode windows of a given host bridge, which bits might enable or disable decode for a given region, or generally worry about providing the sort of info we’d need to make this approach tenable. So as of now, we’ve removed the supporting code, and are placing a bet that using the same information Windows does (and hopefully in the same way) will give us the same level of portability. We actually tried this back in 2.6.31 I believe, but had to disable it because our resource tracking code couldn’t handle all the resources handed us by some ACPI firmware implementations. We (well Bjorn hopefully) should fix that limitation for 2.6.34, and we’ll try again, and hopefully fix quite a few resource mapping related bugs in the process.
|
|
| January 28, 2010 | |
|
For the first time in life, Xorg is being used in a single platform and for a given device only (other devices have used an X11 implementation but using other non-canonical servers, such kdrive’s based – Tiny-X).
Previously Xorg was being packed to run in a huge amount of OSes – mostly Linux and Unix-like distributions – with the characteristic of be architecture portable and able to run on a huge set of video and input devices. In terms of software, this means an extensive amount of code able to cover all of this mentioned. But this is far from the needs of a small and single platform device.
—
Some days ago, at #xorg-devel, Alan mentioned the following:
06:59 < alanc> vignatti: the whole point of Xorg is to drive video output - where else would you possibly sanely put that code?
07:00 < alanc> I think you're going overboard in the drive to remove all code from Xorg
Alan was referring about my previous comment to remove some code of video memory mapping from server… I understand (and respect a lot) his concerns but lemme put this right here: it’s not about removal of code; I don’t even care if the code is in xserver or not; what I do care is about the customization – or more fancy, the true modularization [0] – of Xorg.
—
As discussed on the last X conference, we’re aiming to optionalize [1] lot of components inside Xorg: distros would build all components, satisfying all supported devices and drivers, whereas constrained environments (such as maemo + n900) would use a restrict set only.
So recently I’ve been confusing people’s mind trying to in fact optionalize several components of the server. There are some straightforward modifications on the code like turn off libdrm, vgahw or libxdmcp, but there’s also other more challenger like all the old-school mechanism to initialise cards, to remove cursor support or even to choose if we want or not all bus subsystem. Sometimes we’ll have to be careful to not run out of the protocol. But the truth is: the currently the code is _very_ tied all over the server. It’s not trivial to “get there”.
IMHO the plan traced at XDC looks perfectly clear and while other display systems seems not suitable enough for us yet, I’ll be keep digging on this direction.
[0] the modularization that happened in the version 1.0 was related with drivers going outside the server.
[1] what would be a good word here?
|
|
| January 27, 2010 | |
|
|
|
| January 26, 2010 | |
|
I always try to bring some Norwegian food back with me when I have visited Norway. This year I brought a leg of Fenalår which is a leg of cured mutton. So it is just like the cured ham people eat all over Europe, except from being made from sheep. Anyway I brought it to the Collabora office today to let people have a taste and Marco snapped this picture of me holding the leg.
Of course not all scandinavian food is equally appreciated by our southern neighbours.
|
|
| January 24, 2010 | |
|
|
|
| January 22, 2010 | |
|
Bastien Nocera is known for a lot of things. Most people in Gnome probably knows him as the maintainer of the Totem media player. In the Fedora community he is known as one who deals with a lot of the challenges around multimedia. Here in the UK he is also known as the only frenchman to ever get fully naturalized.
Anyway his latest effort is to try to try and kickstart some work in Google Chromium to get it to use everyone favorite media framework GStreamer. Bastiens explains a lot of his rationale in the Chromium bug report, but I am hoping to get others in the community to chime in too, and even if you don’t have anything new to add, just let Google know you care by starring up this bug report.
I just finished pitching my fledgling GLU3 library to the ARB, and everybody loved it. Quite a few people said that they've hacked up something similar, but much less complete, to get simple demo apps running. A few of the people had functionality not in the library, and it sounds like I may get a few code contributions. It also sounds like it may be included in the OpenGL SDK. Yay me!
For those interested, the doxygen documentation is at:
http://people.freedesktop.org/~idr/glu3
The GIT tree for the code is available at:
git://anongit.freedesktop.org/~idr/glu3
At some point the tree will probably move somewhere that can allow direct commits by people other than me. I'll cross that bridge when I come to it.
Luis already unleashed the word: GNOME 2.28.2 will be released as an online update for openSUSE 11.2 (for reference, openSUSE 11.2 was initially released with 2.28.1). You can currently help testing that everything is fine with the packages by adding the 11.2-test repository and upgrading. Please go ahead and test it, and tell us if it breaks anything. Hopefully, it should work quite fine.
What is really exciting about this is of course not that we're delivering bug fixes to our users ;-) But with 11.2, openSUSE got a new maintenance team, with more community involvement. One of the amazing result is that it is (or at least, feels) much easier now to release online updates for packages, with a process that everybody can follow — it used to be restricted to Novell employees. Another welcome change is that we can finally release new upstream versions as updates, with some obvious restrictions: the new versions should only contain bug fixes, and should fix real important bugs for users.
And this is what enabled the release of GNOME 2.28.2 as an update for openSUSE 11.2: this version bump was lead by Dominique and Magnus. I must admit I'm really glad that I didn't have to do anything ;-) The GNOME policy to only do bug fixes (and updated translations, which is something we also care about!) on a stable branch, and the fact that we're doing a good job at being reliable on this upstream, certainly helped too.
But wait, there's more! If you're crazy about GNOME but still want a stable distribution, you can use GNOME 2.29 on openSUSE 11.2! The Build Service is really helping us here, making it easy to reuse our GNOME 2.29 packages that we have in Factory on 11.2, with nearly no work at all. We have some documentation on how to use GNOME 2.29 on openSUSE 11.2, and testers are welcome. It should work fine and not eat your computer. Testing Factory is also an option, and while it used to be hardly usable in the past, the community is now doing a good job at making sure it works fine most of the time, if not all the time.
Did I mention you can get the latest version of various applications on 11.2 by just adding the GNOME:Apps repository? No need to update the distribution. No need to update GNOME. This is getting insanely cool :-) And both for packagers (nearly no effort to backport packages) and users (latest versions of their preferred applications available on a stable distribution).
Two years ago, I wrote about my switch from my beloved xmms to audacious.
During this 2 years with Audacious, I suffered a bit. It was working quite fine, but I saw no big progress around it. Life happened, and I had to use a network system to play music. I started to use PulseAudio over TCP, but it does not work well, and does not work at all with Audacious (and even if the plugin is provided by upstream). So I decided to dump it.
And some days ago I discovered Sonata, a MPD client. I never liked MPD so far because all clients I found were lame.
But I really like Sonata. It allows me to listen music the way I still want: load everything in one playlist, listen everything randomly or type a song/artist to jump to it directly in the current playlist. It even has some nice feature (lyrics, so I'll be able to song out loud, covers, tag editing…) and is written in Python and GTK+ (some days I may even hack it!).
You can rest in peace x11amp :-p
|
|
| January 19, 2010 | |
|
Here's the seventh and final part of my ongoing series.
One of the grandest sights in Delhi is Humayun's tomb, a predecessor of the greatest mausoleum of them all, the Taj Mahal:
A little bit further down a view on the garden:
From a different corner:
We'll finish with our last panorama that shows the courtyard the Jama Masjid of Old Delhi:
That's all panoramas from this trip. Thanks for your interest.
When I went to Norway this year for Christmas I had the most convenient travel route ever. I had a direct flight from Stanstead Airport to Rygge in Norway. Rygge is a tiny airport, but when you visit people on the southeast side of Oslo like I did, its perfect.
The ticket was also quite reasonably priced even though it was the Christmas holiday.
Yet, despite offering me this ideally set up trip between the two airports on both side which fits me the best, I struggle to dig up any kind of positive feelings for Ryanair.
Was discussing it a bit with Wim and Tim and I think a big part of the reason for this is the constant feeling you get when booking a trip with them that they are trying to make you think their fares are cheaper than they actually are or the feeling that they attempt to ’sneak’ in extra options.
For instance how they charge you for the use of your credit/debit card, a fee that got nothing to do with the actual cost to them and the fact that it is practically impossible to avoid it. As Tim mentioned when we discussed it, if they just included that 5£ fee in the price you wouldn’t think about it and just be happy you got a cheap ticket, instead you feel they are trying to pull a fast one on you and make their prices look even better than they are by pretending mandatory expenses aren’t mandatory.
Maybe Ryanair doesn’t care if I or anyone else actually likes them, I mean I still booked my flight to Norway with them because they where the only ones flying from Stanstead. Yet on the other side I always tend to fly with Easyjet instead of Ryanair if I can, both due to usually flying to better airports and a general feeling that if I search for a flight the price they list for that flight is the price I am actually paying.
Maybe the problem is simply that Ryanair doesn’t understand that even when you are travelling I don’t like the feeling of being taken for a ride
|
|
| January 18, 2010 | |
|
Here's the sixth part of my ongoing series.
Leaving Jodhpur we continued our journey to Jaisalmer, a sand castle of a town in the Thar desert:
In the vicinity of Jaisalmer you'll find cliche sand dunes like you'd expect from a grown-up desert:
Our next station after a long, cold and dusty train ride was Delhi. The principal mosque of Old Delhi is the Jama Masjid:
That's all for now, tomorrow I'll post the rest of my panoramas from this trip, all from Delhi.
|
|
| January 17, 2010 | |
|
Here's the fourth part of my ongoing series.
After Udaipur the next stop on our trip was Jodhpur, the blue city. Which is called that way due of the blue colour of many of its houses:
On a hill next to Mehrangarh Fort, one of the biggest Forts in India (the big sand castle on the hill in the panorama above), you find the Jaswant Thada, a memorial of the Maharajas of Jodhpur:
Inside the fort you'll find highly decorated courtyards:
That's all for Jodhpur, tomorrow I'll post more panoramas, from other stops of our trip.
|
|
| January 16, 2010 | |
|
Here's the fourth part of my ongoing series.
After Hampi we went to Bangalore to attend foss.in. (Fantastic conference, btw. The concerts at the venue are unparalleled.) From there we flew up to Udaipur, in Rajasthan. Udaipur is (among other things) famous for being the place where the central scenes of Octopussy were filmed. Octopussy's famous white palace is on Jagniwas Island in Lake Pichola:
This panorama was taken from another island in the lake, Jagmandir Island, which is visible in the following shot on the left:
Udaipur's scenery, seen from the Maharaja's City Palace down onto Pichola Lake:
That's all for Udaipur, tomorrow I'll post more panoramas, from other stops of our trip.
It's easy to get lost in /sys and not much fun typing long udevadm info command lines all the time. Today, when I had enough of that I sat down and spent an hour to write a little UI for exploring the udev/sysfs tree: udev-browse. I wrote it for my own use, but I am quite sure I am not the only one who wants a little bit simpler access to the device tree. So here you go.
And since everybody loves screenshots here you go:
Two usability hints: if you run udev-browse from a directory in /sys udev-browse will automatically present the device of that path on startup. And if you know the name of a device you can just type it into the device listbox (which is focussed by default). The usual Gtk+ live search will then find you the right entry right-away. It's pretty nifty.
It's written in Vala with minimal dependencies.
I want to keep the maintainership burden for this minimal. So no tarballs, no releases, and I won't reply to your emails regarding this tool, unless they include a good, clean, git formatted patch. Thank you for your understanding.
Anyone wants to package this for Fedora? I'd be very thankful if someone would pick it up.
Have fun.
|
|
| January 15, 2010 | |
|
The new icon selection popup
Fingerprint enrollment
|
|
| January 14, 2010 | |
|
Here's the third part of my ongoing series.
Still in Hampi here's another 360 from the Hills in Hampi down to the Achyutaraya Temple:
A little further down, before dawn, here's a shot from the rocky path leading up the hill:
Our last picture for today is a view down from Hemakuta Hill which is covered with old temples and other structures. In the middle you'll see the large Virupaksha Temple which is still in full use. In that temple you'll find an amazing camera obscura, a physics teacher's dream that projects the temple tower onto a wall (projection, subject, more interesting in reality. Really.)
That's all for Hampi, tomorrow I'll post more panoramas, from other stops of our trip.
|
|
| January 13, 2010 | |
|
As pointed out in the excellent Real-Time Rendering
blog,
Sony Pictures Imageworks has released the documentation and source code for
their Open Shading Language
compiler. It's a slightly
different take on shading languages than GLSL / HLSL / Cg. The idea is that
instead of generating final colors, as in other SLs, shaders compute
information about how a surface / light / whatever interacts. These shaders
are then connected into a network, and complex global illumination is then
calculated by evaluating the network. At least, that's my understanding from
readin the
introduction
for five minutes. 
Pretty cool stuff.
|
|
| January 12, 2010 | |
|
Everyone and his dog seem to call libxml2's xmlCleanupParser() at inappropriate places. For example Empathy does it, and Abiword does it too. Google Code Search seems to reveal at least Inkscape and Dia do it as well.
So, please, if your project links against libxml2 verify that it calls xmlCleanupParser() only once, and right before exiting! And if it calls it more often or somewhere else, then please fix that!
For more information see my post on fedora-devel.
Thanks for your time.
Here's the second part of my ongoing series.
Climbing down the hills, on the banks of the Tungabhadra river you find people washing laundry and bathing, and coracles waiting to be used for a trip through the river.
The greatest of the ancient temples in Hampi is the Vitthala Temple:
Set in in lush green scenery you find the Achyutaraya Temple, which you already might have seen, from above, in yesterday's series:
That's it for today, tomorrow I'll post more panoramas, both from Hampi and other stops of our trip.
|
|
| January 11, 2010 | |
|
Yes, I won't spare you my panorama shots from my recent trip to India. After arriving in Goa Badami was our next stop. It's a very pretty little town in northern Karnataka, and here's a panorama shot from the entrance of the town's famous caves:
Next step was one of the most amazing places on earth, Hampi in central Karnataka. It is definitely one of the greatest sights I have ever seen, and I guess I can say I have seen quite a few in my life. A vast landscape of hills covered in boulders, lush mango and banana plantations, rice fields, dotted with age-old temples and impressive ruins. Locals crossing the river in coracles that look like they belong in a time centuries ago. Women washing colourful laundry in the river, pilgrims wading across the river in their black clothes. An India that delivers every bit of that promise it makes to its visitors. The ruins rival the grand sites in Greece and the landscape sometimes looks like a Crysis in-game scene.
Taken from one of the hills in Hampi this is the sunset:
And then, the next day at dawn make your way up the hills again and you can get an even greater view on the whole scenery:
That's it for today, tomorrow I'll post more panoramas, both from Hampi and other stops of our trip.
Also, if you haven't seen them yet, don't miss my panoramas from my India trip the year before.
Bdale and I (mostly Bdale, of course) finished the TeleMetrum v0.2 design work in December, and this weekend we got boards made and parts ordered and Bdale sat down with his trusty electric skillet and built 3 new boards. The new design has an integrated GPS receiver and patch antenna, and is otherwise fairly similar in design to v0.1.
Here’s the front side of the board:
From the left, you’ll see a connector for an external power switch and the two ejection charge circuits, a battery connector for a single 3.7V lipo cell, the GPS patch antenna, a 4-pin debug connector, the piezo buzzer and the new 8-pin companion board connector. We weren’t happy with the connectors used on the v0.1 board and finally found these Tyco Micro-MaTch parts which take up a modest amount of board space (more than pico-blade connectors, less than regular pin blocks), have a locking option and crimp on to standard ribbon cable. They’re also bright red and surprisingly low in profile.
And here’s the back side:
Elements on this side include the new 100μF cap in the upper left corner which sits on the 3.3V supply to try and keep the CPU alive through minor power glitches. Below that is a new package containing a pair of FETs for the ejection circuits. We used discrete FETs in v0.1, but this device has better specs for our needs (lower on resistance, etc). The USB connector was pulled in-board far enough to keep it from hanging over the edge. Right of that is the new data logging chip, and right of that is a U.FL connector in case you want to use an external GPS antenna. We supply power to that connector as most external GPS antennas include their own LNA. And, of course, to the right of that is the Skytraq Venus 634 GPS receiver.
Below and to the right of the GPS receiver is the cc1111, to the left lies the accelerometer and then the barometric pressure sensor above the 5V boost regulator which powers the accelerometer. We haven’t found any high-G accelerometers that run on 3.3V yet. Finally the two tiny 5-pin chips are the USB LiPo charger and the 3.3V regulator. What you can’t see easily are a pile of 0402 passive components scattered across the board. Even close up, they’re hard to pick out by eye.
The only hardware ‘bug’ was in the reset logic — the new board was designed with a much larger capacitor on the reset line than the old board. The debug code would only hold the reset line low for a brief instant, sufficient for the old capacitor value but not the new one. Instead of fixing the code, Bdale decided to try a smaller capacitor value and found that it worked just fine. After that, the board came up just fine and the updated firmware was flashed into the CPU.
The only significant software change was that the data logging part changed from a 25LC1024 1Mbit eeprom to an AT45DB161D 16Mbit DataFlash. This required writing a new driver, but fortunately much of the code could be copied from the 25LC1024 driver. Because the AT45DB161D comes from a family of similar-but-different parts ranging from 1Mbit to 64Mbits, I decided to make the code automatically adapt to the installed part, detecting which one was attached and adjusting the driver.
The story here is that the configuration data didn’t appear to be getting preserved across reboots — we use the last block of the data logging part to hold configuration data, including call sign, sensor calibration values and flight parameters. A bit of testing and we found that the code to read/write the device worked perfectly. It turns out that a premature optimization in detecting which kind of flash part was installed had a race condition when multiple threads were trying to access storage at the same time, resulting in the configuration data being left uninitialized. Oops!
The TeleMetrum firmware has a clever hack for selecting between ground mode (for fetching data from the device or altering the configuration) and flight mode (prepared to fly the rocket). It switches between these by detecting whether the board is upright (flight mode) or not (idle mode). However, the accelerometer must be calibrated to tell the difference. What never occurred to us was that if the calibration data was broken enough, the device might always come up in flight mode. In that mode, it isn’t listing to either USB or the radio link, so it’s impossible to fix the accelerometer calibration data.
A bit of brainstorming led to a fairly simple hack — check to see if one of the pins on the companion connector was shorted to ground at power on time, if so, force the computer to enter idle mode. Pin 1 of the companion connector is ground, and fortunately, pin 2 was the SPI clock pin, normally output-only, so we could safely use that in this mode as any companion device shouldn’t ever pull that low.
As of this evening, three boards are built and mostly tested; the radios appear to work, GPS tracks satellites and the beeper makes plenty of noise. Still to check is whether the deployment circuits will fire an ematch (we’ve tested the design before, just not this specific implementation).
Next weekend, we’re off to linux.conf.au in Wellington, New Zealand where we’re scheduled to give a presentation on the hardware and software in TeleMetrum. We’ll have v0.2 boards to show off, so come and see them in person.
With v0.1, we used the same board design for both flight computer and ground station, TeleDongle. For TeleDongle, we just left most of the components off of the board and loaded alternate firmware. For v0.2, we’re planning on building a separate TeleDongle board; that design is finished but no boards are made yet.
Once we’re happy with the design, we’ve got big plans to get more boards made so we can let a few friends buy them for use them in their own rocket projects. That should happen in the next month or so. Once we’ve gotten enough testing done, and made sure that other people can actually operate them without hand-holding from us, we’ll make them available for sale to the general rocket-flying public.
Beyond that, we’ve got plans to build more stuff:
A stand-alone ground station, called TeleTerra, that would include an LCD readout and flight data recording so you wouldn’t need a laptop during the flight.
A companion board, called TelePyro, to control 8 additional pyro channels. These could be used for almost anything from air starts to staging or any other whacky plans.
|
|
| January 05, 2010 | |
|
|
|
| January 04, 2010 | |
|
Discovered a blog post today from Philip Jägenstedt at Opera. The post describes the new HTML5 enabled Opera (alpha)( release and how it uses our favourite media framwork GStreamer. Great to see this available for easy download now and a big thanks to Opera for their work in supporting HTML5 and the Ogg codecs.
Philip got a lot of interesting details in that blog post so I really recommend reading it.
Opera also makes the source code of their copy GStreamer available as a git repo which should make merging any changes they do to GStreamer very easy, a big thanks for that.
:: whot@barra:~> ls -R /etc/xorg*
/etc/xorg.conf
/etc/xorg.conf.d:
10-synaptics.conf 97-wacom.conf 99-evdev.conf
Section "InputDevice"
Identifier "touchpad"
Driver "synaptics"
Option "AutoServerLayout" "on"
EndSection
Section "InputClass"
Identifier "synaptics-catchall"
Driver "synaptics"
MatchIsTouchpad "on"
EndSection
Section "InputClass"
Identifier "evdev-catchall"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "vendor-quirk"
MatchVendor "SomeVendor"
MatchDevicePath "/dev/magicdevice"
MatchIsTouchpad "on"
Option "Quirk" "on"
EndSection
|
|
| January 03, 2010 | |
|
|
|
| December 31, 2009 | |
|
India is a weird and beautiful country. And I am too lazy to retouch my photos.
|
|
| December 30, 2009 | |
|
Just in time for the new year, I’m pleased to be able to say that the Bluetooth DUN package is now in the Maemo Extras repository. This is the primary location for community packages that have been through a community QA process that tries to ensure the packages are safe for ‘normal’ users. If you don’t have the extras repository turned on, you can do so by following the instructions here.
New XMMS2-Scrobbler release. Better than ever: multi-scrobbling is supported now. libre.fm users rejoice! See README for the details.
|
|
| December 29, 2009 | |
|
I like UI and I’m not gay.
Some time ago someone posted a comment, complaining about the white fonts over the dark background in my blog, which makes the read be difficult. The guy teased me, recommending an ironic page where shows how hard is to read texts like this. He was right…
So now I changed wordpress to a totally opposite theme called “White as Milk”. Yay, total white and easy to read now! Let’s see how long I’ll get sick of that interface.
|
|
| December 28, 2009 | |
|
|
|
| December 27, 2009 | |
|
Today, the applet code is dropped from gnome-applets. Since gnome-settings-daemon now includes the notification icon (automatically appearing/disappearing), the applet is no longer needed.
Back in 1999 (Nov 29) it was the gswitchit applet that was committed to SourceForge. After GUADEC in Dublin it got merged into GNOME, some bits and pieces went to gnome-control-center. The rest is history…
The technology goes on. The functionality stays and improves. The initial point, the applet is gone.
|
|
| December 26, 2009 | |
|
Just a thought is this something that should be deleted? This seems to be using about 7% of my RAM
I don’t have words for it.
|
|
| December 25, 2009 | |
|
 |
 |
|
| planet.fd.o | ||
planet.freedesktop.org is powered by Planet,
and the freedesktop.org community.
 
 
|
||
 |
 |
|
|
|
| Planetarium | ||
|
Planet Debian Planet Fedora Planet Gentoo Planet GNOME Planet GStreamer Planet IM Planet Jabber Planet KDE Planet Kernel Planet Mozilla Planet OpenOffice.org Planet SuSE Planet Xiph |
||
|
|
