fidzu : freedesktop

A number of people have asked me questions along the lines of "can I play my favorite Quake 3 mod with your package on Maemo?" The answer used to be that you could not, due to changes in the Client Game (cgame) module. I've now fixes these issues (mostly absolute vs. relative touchscreen events) so that an unmodified cgame will work correctly.

The short answer: yes, your favorite mod should now work.

I have done absolutely no testing other than checking that the vanilla, unmodified QVM's shipped on the Quake 3 CD work as expected. So your millage may vary.

There are still a couple of issues with UI interaction, but since this is a highly requested feature, and I have a flight to catch in some hours, I'm pushing ioquake3 (1558-maemo6) to extras-devel now.

Also, there are two cvar's you might like to tweak: sensitivity and accel_sensitivity.

Pro-tip: the key combination "Fn (Blue Arrow) + =" is Escape, and "Fn + Sym" is console up/down. Yes, eventually I will write some better release notes. :-)

10 Mar 2010 9:41am GMT

In the GNOME beer event, I had a nice chat with ebassi about the problems around our build configuration system and how things like CMake, SCons and Waf do not get the full picture and do not cover some of the really strange corncercases that autotools supports and therefore, coming up with a solution would be a 1 year work with a team of really experienced engineers.

As stubborn as I am, I decided to prove him wrong so I give you BuilDj:

The Problem

My main problem with our current Autotools situation are these:

• It is not portable as it encourages strong use of Bash and command line tools which ends up making it really hard to use on a non POSIX system, you know, like that used by 92% of the desktop users, even if the source code itself is perfectly portable.
• It gets on your way, a lot. Sometimes I refrained from writing some testcases just to avoid to add the Autotools boilerplate.
• Really bad documented, still.
• You need to learn M4/Autoconf, Automake, Make and Bash to use it properly, as if learning C, C++ or Vala and worrying about the problem the programmer is trying to solve is not hard enough.
• None extends it because it's hard to extend.
• Its hard to read and understand even if you eventually wrote it yourself, makes code refactoring a big pain.
• You simply can't parse autotools and have an IDE or a continous integration tool to understand what's there.
• The most important one, it scares peoples away, damaging our mindshare, making potential contributors go away. It drains the fun out of our platform.

Requirements

We need a human+machine friendly project description format, that it's pleasant to the eye when you read it, that it's intuitive enough to let you understand what's going on even if you never saw it before.
A format that gets out of your way!

It should support all of the common tasks a GNOME maintainer does (in-line .pc and .desktop file definition, mkenums, gobject introspection support, cross-compilation support, pkg-config oriented, xdg mimetype registration/definition, integration with intltool), but it should suppor them in a meaningful and unobtrusive way.

It should not be a programming language, but support embedable programming extensions with a well documented API, so that IDEs can integrate it.

My Proposal

A JSON description format called BuilDj that is build-system agnostic (although its reference implementation is done with Waf)

{
        "project":
        {
                "name": "BuilDj Test",
                "version": "0.0.1",
                "url": "http://www.codethink.co.uk"
        },
        "requires":
        {
                "gtk+-2.0": 
                {
                        "type": "package",
                        "version": "2.14",
                        "mandatory": "True"
                }
        },
        "targets":
        {
                "my_shared_lib":
                {
                        "type": "sharedlib",
                        "tool": "cc",
                        "input": ["lib.c"],
                        "version": "1.2.3"
                },
                "my_gtk_program":
                {
                        "type": "program",
                        "tool": "cc",
                        "input": ["gtk_program.c"],
                        "uses": ["my_shared_lib"],
                        "packages": ["gtk+-2.0"]
                },
                "my_vala_program":
                {
                        "type": "program",
                        "tool": "vala",
                        "input": ["vala_program.vala"],
                        "packages": ["gtk+-2.0"]
                }
}

I don't even need to explain what that means right? By the way, this stuff already works, check the git repository.

Currently it is implemented as a waf wscript that parses the project.js json file, I'm not really interested in entering the build system wars but focuing on having a reference implementation of the format.
I choosed waf because it was the only one that offered most of the features I want as an approachable API and it only adds python as a dependency.

Implementations of the format in other systems are more than welcome, but current development will stick to waf in the foreseeable future.

I'm planning to propose and mentor this work as a Summer of Code project so that we can implement the missing basic features and support for a few GNOME apps.

There's a lot of work to do, support for C++, library and function checking, system type sizes, full cross compilation support. We already have some mockups and plans for those, and the waf maintainer has shown himself quite happy to accept patches upstream for the general purpose tools and that make things easier.

Despite the missing features, it surprisingly itches some of my own scratches already.

P.S. Anjuta and MonoDevelop guys, if you're listening, I'd love to get your feedback!

09 Mar 2010 11:18pm GMT

The slides for my talk about the audio infrastructure of Linux mobile devices at BOSSA 2010 in Manaus/Brazil are now available online. They are terse (as usual), and the most interesting stuff is probably in what I said, and not so much in what I wrote in those slides. But nonetheless I believe this might still be quite interesting for attendees as well as non-attendees.

The talk focuses on the audio architecture of the Nokia N900 and the Palm Pre, and of course particularly their use of PulseAudio for all things audio. I analyzed and compared their patch sets to figure out what their priorities are, what we should move into PulseAudio mainline, and what should better be left in their private patch sets.

09 Mar 2010 6:04pm GMT

A few weeks ago, the GNOME Foundation has been contacted by the organizers of the Idlelo conference in order to get a GNOME presence during the event. Quoting the website of the event:

IDLELO is one event for FOSS practitioners, developers and advocates as well as governments to showcase results, share experiences and challenges, review progress on the continent in diverse domains and chart a way forward for an African future grounded in true ownership of technology. IDLELO is therefore a premier international forum for the presentation of research results in Free and Open Source Software (FOSS) in Africa.

The event will occur in May, in Accra, Ghana.

There have been many discussions in the past about how to get more community involvement in Africa, and there's no magical solution. But a good first step is, for sure, to be present at events that are being organized on the african continent. We're already sending Luis de Bethencourt to FOSS Nigeria, and we want to be at Idlelo too.

If everything goes well, the amazing Fernando will go deliver training sessions before the conference itself; but we need one more person to man a booth during the conference. While this is not a hard requirement, we'd still like to have a GNOME Foundation member who feels empowered to talk in the name of the Foundation. If you're interested in representing GNOME at Idlelo, please get in touch with the board. I'm sure you'll enjoy it!

08 Mar 2010 11:20pm GMT

Being at the GNOME UX Hackfest even for just one day was an energizing experience, sort of eye opener in a way. And it made me think about the situation GNOME is been for a while (desktop-devel being dead, foundation-list too alive, and things like that...)

I tried to remember what made me contribute, and I remember that it was posts like this, the ones that made me excited and pushed me to spend endless hours learning about C and this GObject thingie, so that I can improve the very desktop I loved to use, and I could help to prove to the world that great and usable products could be made the opensource way. At some point down that path, I made GNOME technologies a goal of its own.and I stopped focusing on creating a great desktop (prolly because up to some extend the experiencie of trying to implement those ideas was not as pleasant).

I have the feeling that we, hackers, have done a pretty bad job at encouraging our designers among the community to challenge us and push the boundaries and goals of our own technologies further, actually, we've let those boundaries to stop the designers' proposals. Bad, bad, bad idea.

This is an open letter to the GNOME design community:

Folks, *BE VOCAL*, really, please, challenge us, communicate, blog post like there's no tomorrow, propose your stuff, draw mockups, file bugs... take over the project!

It can be difficult at times, we hackers can be quite energy stoppers, but please, ignore us, push design back in our veins. I want jokes and fun back to the project, I want pirate hats in our hackergotchis, I want Rupert jokes, I want a new planet theme, I want crazy pictures of crazy GNOME hackers doing crazy things. I want that magic back, and I have the gut feeling you can bring that back guys. It is only through design that we will enter new grounds, innovate and excite new contributors.

Update: RubenV just pointed me out to this example that nails exactly what I'm trying to communicate here.

08 Mar 2010 11:59am GMT

If you're still wondering what happened during the Usability hackfest, then you clearly missed a lot of blog posts. The good news is that you can catch up with all the links being collected on the Hackfests, or you can cheat and go read Máirín's coverage, since she did an amazing job writing about what was being discussed.

I was there only for the last two days; the original plan was to attend a bit more of the event, but the travel from France to London took an unexpected 12 hours. I still had some good and useful time there, that I mostly used to get a good overview of what people are working on, and how this can be integrated in a GNOME roadmap. Here are some highlights:

• While I missed the discussion about nautilus, it seemed most people at the hackfest agreed on streamlining the nautilus user interface. I'd love to try the prototypes that were worked on: most of the proposed changes make sense to me. But getting rid of tabs and/or the split view will certainly trigger various reactions, and that's something that we cannot ignore...

• Thomas je parle français couramment Wood was kind enough to let me use his laptop charger nearly all the time - I had one, but not for the right laptop...

• Charline reported about a usability review of empathy, and this was definitely instructive. It's always fun to look at a user interface and finds what's wrong and what can be improved. In some way, it reminded me of some usability reviews that the usability team was doing for various applications a few years ago. That's an effort that we've been missing lately, and I'd love to see someone revive this!

• The work on the new control center seems to be moving along nicely. We should see the results in the next development cycle; don't be afraid to help Thomas if you're interested in this!

• While discussing preferences, and removing some of them that we think most (as in a huge percentage) people don't use, we mentioned the fact that when we remove some settings from the various configuration tools, a lot of people get unhappy, to say the least. This is understandable, but we also always pointed out that it should be easy to write a small tool to enable people to change those settings graphically again. That never happened, but we'd like to avoid further unhappiness. This is how the idea of GNOME Plumbing was born. And I foolishly proposed to implement this.

• It was funny to see Garrett breaking his openSUSE installation. Except that it shouldn't break this way when using GNOME:Factory on 11.2. Oops.

• I had a good chat with Jon about GNOME 3. There's so much we can deliver during the whole GNOME 3.x cycle... We're focusing on 3.0 right now, but we need to prepare the following releases too. It was motivating to get reminded of the various areas we should explore, and motivation is something that was most welcome :-)

• It was good to catch up with Lucas, just a few days before Julia magically appeared :-) He's still one of my heroes.

• On Friday morning, Bastien told to Mairin, Garrett, Jakub and Hylke: okay, you want tools for designers; we're a bunch of hackers here, but we need you to design the tools you need. This resulted in a good discussion. Except that now, we really need some people to sit down and implement this. I guess this could be an interesting Summer of Code project!

• Seeing Willie get hopes for usable accessibility support in GNOME Shell was a real pleasure. It's been a hard topic for months, and knowing that there might be some light at the end of the tunnel is already good news.

• Matthew invited me to a card sorting session about settings and how to group them. It was a new experience for me, and seeing someone struggle to organize settings was eye-opening: I got the feeling that even with just one person doing this seriously, we can improve the overall experience for many users. I'm intrigued how usability people deal with different people having conflicting behaviors, though.

Many thanks to Canonical and Google for sponsoring this hackfest, and also thanks to Klaas and Novell for letting me go on a short notice :-)

I have high hopes that putting all those designers and usability people in one room together during one week will also make the GNOME Usability team move forward again. Usability is an essential part of our DNA, but we've been slowing down our efforts there, instead of accelerating as we should have done. This hackfest should put us back on track!

08 Mar 2010 2:15am GMT

So after battling with shader, thinking my compiler was giving me crap, i noticed that the w component was forced to 0.0 ... well of course now taking vertex input format into account things work. So here it's tri-flat being render using a shiny compiler infrastructure. I also added a todo list in r600_winsys.h (it's big but it's the begining). So now i will finish plugin the state thing so tri-flat is actually flat and not gouraud shaded, then some cleanup in the flush so i just flush when gallium ask for it. Then it's about growing the shader compiler to support more instruction, this should be "easy". I hope to have glxgears soon. Anyway here is a screenshot (i unplugged the clear stuff now that i got the other part working i will soon plug the clear gallium helper stuff).



Oh i forgot to stress that it only works on r7xx because my main computer has a no fan r7xx GPU :) once i got gears working i will make sure that r6xx are working too (or just send me no fan r6xx gpu).

07 Mar 2010 8:56pm GMT

@IanRomanick, with his post on a little cultural problem that VIA encountered.

I actually had some issues when unichrome.sf.net was first created in Q2 2004. Some commit emails would get caught by the sf.net spamfilter. There was an interesting struct in this headerfile.

A quick grep of VIAs current codedrops does not show much of an improvement. The same structs name is now preceded with "NEW".

07 Mar 2010 1:01am GMT

You'd think with a name like that they'd have better performance.

This is the old Apollo MVP4 chipset used in Super Socket 7 sytems used primarily with AMD K6-2 and K6-III CPUs. It used the Trident Blade3D graphics core, so you know it was full of win.

06 Mar 2010 11:33pm GMT

I've just played some music over HDMI using radeon KMS and RV730 card! My local patch rewrites the way we choose HDMI block for encoder, drops current hacks and make it work on more hardware. Plus of course it adds some single bits for DCE 3.2 GPUs. It needs some cleaning, splitting maybe and fixing resume. I hope to post it in day or two, hopefully in time for getting it into 2.6.34 :)

[read more]

05 Mar 2010 7:17pm GMT

While GStreamer has been working on Windows for a long time and one can compile GStreamer using Visual Studio, the lack of pre-made binaries for Windows developers has been a bit of an issue. Various groups and people have tried providing windows binaries for a while, but most efforts have stalled after a short while. The GStreamer winbuilds project however seems quite solid however and have now been doing good windows packages for quite a while. If you have been looking for Windows builds for GStreamer this is a good place to start. They already have a list of users on Windows and the reason I became aware is that the jokosher guys are using it for their windows porting effort.

04 Mar 2010 2:43pm GMT

'Can you get cp to give a progress bar like wget?'

04 Mar 2010 1:20am GMT

well, that title should get me a few hits :)

Anyway, the other day I had to set up one of these 3G mobile internet USB modems on a Fedora 12 box. The dongle in question was from Vodafone, purchased about a week and a half ago. It didn't work out of the box, though in hindsight it should have. So for anyone who's googling around on how to set this up (or whether it can be set up at all), here's the gist.

The dongle is a HUAWEI Technology usb modem, Vendor number 12d1, product id 1520. The modem looks like a mass storage device on account of the manufacturer trying to be smart. If you plug the modem in, dmesg has this to say:

usb 1-2: new high speed USB device using ehci_hcd and address 6
usb 1-2: New USB device found, idVendor=12d1, idProduct=1520
usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0
usb 1-2: Product: HUAWEI Mobile
usb 1-2: Manufacturer: HUAWEI Technology
usb 1-2: configuration #1 chosen from 1 choice
scsi5 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 6
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 5:0:0:0: CD-ROM            Vodafone CD ROM (Huawei)  2.31 PQ: 0 ANSI: 2
sr1: scsi-1 drive
sr 5:0:0:0: Attached scsi CD-ROM sr1
sr 5:0:0:0: Attached scsi generic sg4 type 5

As I said above, these modems look like mass storage devices and need to be switched to the actual modem mode. The nifty program usb_modeswitch does exactly that, but alas, only in version 1.1.0 for this particular device. This version also includes the udev rules to make everything work automagically. At the time of writing, Fedora 12 didn't have 1.1.0 available yet (Bug 563503). So you can poke the maintainer to update the package (see the bug) or grep the spec file from that bug report and build the rpm yourself. Once built, install, plug the modem in and the dmesg looks a lot better:

usb 1-2: new high speed USB device using ehci_hcd and address 8
usb 1-2: New USB device found, idVendor=12d1, idProduct=1465
usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0
usb 1-2: Product: HUAWEI Mobile
usb 1-2: Manufacturer: HUAWEI Technology
usb 1-2: configuration #1 chosen from 1 choice
scsi7 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 8
usb-storage: waiting for device to settle before scanning
scsi8 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 8
usb-storage: waiting for device to settle before scanning
usbcore: registered new interface driver usbserial
USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
USB Serial support registered for GSM modem (1-port)
usbcore: registered new interface driver option
option: v0.7.2:USB Driver for GSM modems
option 1-2:1.0: GSM modem (1-port) converter detected
usb 1-2: GSM modem (1-port) converter now attached to ttyUSB0
option 1-2:1.1: GSM modem (1-port) converter detected
usb 1-2: GSM modem (1-port) converter now attached to ttyUSB1
option 1-2:1.2: GSM modem (1-port) converter detected
usb 1-2: GSM modem (1-port) converter now attached to ttyUSB2
option 1-2:1.3: GSM modem (1-port) converter detected
usb 1-2: GSM modem (1-port) converter now attached to ttyUSB3
usb-storage: device scan complete
usb-storage: device scan complete
scsi 8:0:0:0: Direct-Access     Vodafone Storage (Huawei) 2.31 PQ: 0 ANSI: 2
scsi 7:0:0:0: CD-ROM            Vodafone CD ROM (Huawei)  2.31 PQ: 0 ANSI: 2
sd 8:0:0:0: Attached scsi generic sg4 type 0
sd 8:0:0:0: [sdd] Attached SCSI removable disk
sr1: scsi-1 drive
sr 7:0:0:0: Attached scsi CD-ROM sr1
sr 7:0:0:0: Attached scsi generic sg5 type 5

Whoopdi-doo. The modem is recognized as modem and we can go and set it up. Now, I don't get a warm fuzzy feeling when editing config files that I'll likely not look at again for a while, so I chose the clicky-pointy route: the magnificent NetworkManager. Click on the NM icon on your desktop, and it'll look like this:



Click on new connection, then jump through the wizard and you're done.










Now, all you have to do whenever you need to connect to the internet is plug the modem in, wait for a few seconds and then click onto your connection:




The sad thing is, that if usb_modeswitch 1.1.0 was installed already, it would have truly been plug and play, even though Vodafone claims that Linux is not supported. Oh well, at least this way I've got something to write about to shoo away those tumbleweeds on my blog.

Many thanks to Laurianne for letting my try the dongle on the Mac first (and letting me install the ridiculous piece of software Vodafone ships with the dongle) and Tom for running Debian which already was on usb_modeswitch 1.1.0 - showing that the modem works.

03 Mar 2010 9:47pm GMT

Decided to join the early adopters crowd today and use the desktop of the future by switching to using GNOME Shell on my desktop. Luckily with Fedora its dead simple, you just yum install gnome-shell and then switch using the desktop effects widget under Preferences. Scarily simple.

So far GNOME shell has been very stable for me and the user experience has been mostly good. Still feels a little alien compared to what I was used to before, but nothing annoyingly alien. Only irritant so far is that the clock on the shell is using the luddite AM/PM time system instead of the proper 24H clock and I can't figure out how/where to fix it.

Will report back next week if I decided GNOME shell is here to stay on my desktop or if its still needs some more love before I am ready to let it rule my life.

03 Mar 2010 5:19pm GMT

i have created a Keyboard Layout that can be operated with both hands and optional with only one hand.
http://www.entikey.z11.de/

i have also packed a deb-packet, but i think it would be better to have it implemented in the X Window project.

could you add my changes from the deb-packet to the repository?

entikey-1.0_i386.deb

03 Mar 2010 2:13am GMT

Thanks to David, I finally fixed the header title of my blog to spell my name in Hebrew properly. David, don't hesitate to let me know if it still sucks :)

02 Mar 2010 5:43pm GMT