X.Org

Last weekend was fosdem, where I showed a few more things working on freedreno (compiz, q3a).  The recording of the talk is provided by phoronix.  Although unfortunately the mic was closer to the audience than me (and I'm not really a loud speaker) ... [More] , and the camera remained pointed at the projector while I was showing the demo, so you miss the exciting bits.So I re-ran the demo and captured it with my advanced cinematic skillz, and without the backlight hickups which plagued the original demo (but had nothing to do with freedreno... have I mentioned before that drivers/video/msm is made of fail?).Full video here.I still need to fix support for mip-map textures (which you may have noticed in the q3a part), and there are a couple rendering bugs with the unity plugin in compiz, but at least the other compiz plugins I've tried so far seem fine.  Until now I have not put much (or really, any) focus on performance and there is definitely some low hanging fruit on the performance front.  Unfortunately some of the issues, like proper synchronization between xorg and gl/dri2 client, and flipping rather than doing fullscreen presentation blits, will I think require a proper drm kernel driver.  Although I suspect there is room for some compiler optimization and a few other things. [Less]

The slides from my FOSDEM talk are now available. I would have gotten them out sooner, but I caught a bit of a cold on the way home. I guess averaging 3 hours of sleep per night wore my resistance down. Who knew? In any case, the talk went ... [More] really well. The attendance was low due to not being in the printed schedule (I got my information in really late) and being scheduled across from Luc's graphics talk in the main track. It was really good to chat with the Wine developers... I continue to be amazed that thing works. I don't envy them at all... but I'm glad they're there. [Less]

Now that my kernel modesetting lockig rework has landed in Dave's drm-next tree and is gearing up for inclusion into 3.9 I've figured it's time to also post my little intro here: The aim of this locking rework is that ioctls which a compositor should ... [More] be might call for every frame (set_cursor, page_flip, addfb, rmfb and getfb/create_handle) should not be able to block on kms background activities like output detection. And since each EDID read takes about 25ms (in the best case), that always means we'll drop at least one frame. The solution is to add per-crtc locking for these ioctls, and restrict background activities to only use the global lock. Change-the-world type of events (modeset, dpms, ...) need to grab all locks. Two tricky parts arose in the conversion: A lot of current code assumes that a kms fb object can't disappear while holding the global lock, since the current code serializes fb destruction with it. Hence proper lifetime management using the already created refcounting for fbs need to be instantiated for all ioctls and interfaces/users. The rmfb ioctl removes the to-be-deleted fb from all active users. But unconditionally taking the global kms lock to do so introduces an unacceptable potential stall point. And obviously changing the userspace abi isn't on the table, either. Hence this conversion opportunistically checks whether the rmfb ioctl holds the very last reference, which guarantees that the fb isn't in active use on any crtc or plane (thanks to the conversion to the new lifetime rules using proper refcounting). Only if this is not the case will the code go through the slowpath and grab all modeset locks. Sane compositors will never hit this path and so avoid the stall, but userspace relying on these semantics will also not break. All these cases are exercised by the newly added subtests for the i-g-t kms_flip, tested on a machine where a full detect cycle takes around 100 ms. It works, and no frames are dropped any more with these patches applied. kms_flip also contains a special case to exercise the above-describe rmfb slowpath. For anyone curious about some of the details of this rework or ARM drm driver writers needing to port out-of-tree stuff I suggest to just read through the patches - I've tried really hard to properly document things in commmit messages and note about the implications of the new design. The downside of this all is that we can now enable some really paranoid inter-frame jitter checks and vblank counter timestamp checks in the kms_flip testcase. After all, no frames should be dropped any longer. But it turns out that a lot of the different platforms still have small issues here and there with races and other inconsistencies like completing a page flip immediately right after a modeset. So there's still plenty of work to do until we have perfect pageflip support. And there's also a few funny issues like racing gpu hangs against pageflips, client crashes against pageflips or trying to flip overlays and cursor on the same vblank as the underlying framebuffer. Ville Syrjälä and other guys at Intel and elsewhere are working on this. So stay tuned. [Less]

At FOSDEM, I had a mainline talk about "Open ARM GPU Drivers", going over all the projects and GPUs, talking about the developers doing the hard reverse engineering work and the progress that they have made so far. I will write up a blog entry ... [More] summarizing this talk soon, but for now i will just talk about the Lima demo i showed at the end of the talk.Let me get straight to the main point before delving into details: We now have a limare (our proto/research driver) port of Quake 3 Arena which is running the q3a timedemo 2% faster than the binary driver. With 3% less cpu overhead than the binary driver to boot!Here is the timedemo video up on youtube. It is almost pixel-perfect, with just a few rounding errors introduced due to us being forced to use a slightly different vertex shader (ESSL, pulled through the binary compiler instead of a hand coded shader). We have the exact same tearing as the binary drivers, which are also not synced to display on the linux-sunxi kernel (but ever so slightly more tearing than the original ;)).This Q3A port is not playable for a few reasons. One is, i threw out the touchscreen input support, but never hacked in the standard SDL based input, so we have no input today. It should be easy to add though. Secondly, i only include the shaders that are needed for running the timedemo. The full game (especially its cut scenes) requires a few more shaders, which are even simpler than the ones currently included. I also need to implement the equivalent of glTexSubImage2d, as that is used by the cut-scenes. So, yes, it is not playable today, but it should be easy to change that :)We are also not fully open source yet, as we are still using the binary shader compiler. Even after begging extensively, Connor was not willing to "waste time" on hand coding the few shaders needed. He has the necessary knowledge to do so though. So who knows, maybe when i push the code out (the q3a tree is a breeze to clean, but the lima code is a mess, again), he might still give us the few shaders that we need, and we might even gain a few promille performance points still :)I will first be pushing out the q3a code, so that others can use the dumping code from it for their own GPU reverse engineering projects. The limare code is another hackish mess again (but not as bad as last time round), so cleaning that up will take a bit longer than cleaning up q3a.Why frag like it is 1999?Until now, i was mostly grabbing, replaying, and then porting, EGL/GLES2 programs that were specifically written for reverse engineering the mali. These were written by an absolute openGL/openGLES newbie, someone called libv. These tests ended up targetting very specific but far too limited things, and had very little in common with real world usage of the GPU. As most of the basic things were known for mali, it was high time to step up things a level.So what real world OpenGL(ES) application does one pick then?Quake 3 Arena of course. The demo four timedemo was the perfect next step for reverse engineering our GPU.This 1999 first person shooter was very kindly open sourced by ID Software in 2005. Oliver McFadden later provided an openGLES1 port of ioquake3 for the Nokia N900. With the Mali binary providing an OpenGLES1 emulation library, it was relatively easy to get a version going which runs on the Mali binary drivers. Thank you Oliver, you will be missed.The Q3A engine was written for fixed 3D pipelines and this has some very profound consequences. First, it limits the dependency on the shader compiler and allowed me to focus almost purely on the command stream. This completely fits with the main strategy of our reverse engineering project, namely it being 2 almost completely separate projects in one (command stream versus shader compilers). Secondly, and this was a nice surprise when i started looking at captures, the mali OpenGLES1 implementation had some very hardware specific optimizations that one could never expose with OpenGLES2 directly. Q3A ended up being vastly more educational than I had expected it to be.With Q3A we also have a good benchmark, allowing us to get a better insight into performance for the first time. And on top of all of that, we get a good visual experience and it is a dead-certain crowdpleaser (and it was, thanks for the cheers guys :))The only downside is that the data needed to run demo four is not available with the q3a demo release and therefor not freely downloadable. Luckily you can still find Q3A CDs on ebay, and i have heard that steam users can easily download it from there.The long storyAfter linuxtag, where i demoed the rotating companion cube, I assumed that my knowledge about the mali was advanced enough that bringing up Q3A would take only a given number of weeks. But as these things usually go, and with work an real life getting in the way, it never pans out like that. January 17th is when i had q3a first work correctly, time enough to worry about some optimization still before FOSDEM, but only just enough.I started with an android device and the kwaak3 "app", which is just Olivers port with some androidiness added. I captured some frames to find out what i still missed with limare. When i finally had some time available, i first spent it cleaning up the linuxtag code, which i pushed out early december. I had already brought up Q3A on linux-sunxi with the mali binary drivers, which can be seen from the video i then published on youtube.One thing about the youtube video though... Oliver had a tiny error in his code, one that possibly never did show up on the N900. In his version of the texture loading code, the lightmaps original format would end up being RGB whereas the destination format is RGBA. This difference in format, and in-driver conversion, is not supported by the openGLES standard. This made the mali driver refuse to load the texture, which later on had the driver use only the primary texture, even though a second set of texture coordinates were attached to the command stream. The vertex shader did not reflect this, and in my openGL newbieness i assumed that Ben and Connor had a bug in their vertex shader disassembler. You can clearly see the flat walls in the video i posted. Once i fixed the bug though, q3a suddenly looked a lot more appealing.I then started with turning the openGLES1 support code in Quake's GLimp layer into a dumper of openGLES1 commands and data in a way that made it easy to replay individual frames. Then i chose some interesting frames, and replayed them, turned them into a GLES2 equivalent (which is not always fully possible, alphaFunc comes to mind), and then improved limare until it ran the given frames nicely through (the mali has hw alphaFunc, so limare is able to do this directly too). Rince and repeat, over several interesting frames.By the evening of January the 16th, i felt that i knew enough to attempt to write a GLimp for limare. This is exactly when my father decided to give me a call. Some have met him at Le Paon last Friday, when he, to my surprise, joined us for a beer after work as his office is not far away. He remarked that i seemed "a bit on edge" when he called on the 16th. Yes, i indeed was, and how could i be anything else at a time like this :) I hacked all night, as at the time i was living purely at night anyway, and minutes before my girlfriend woke up i gave it my first shot. Crash, a stupid bug in my code. I told my girlfriend that i wouldn't join her for "breakfast" before i went to bed, as i was simply way too close. By the time she left for work, i was able to run until the first few in-game frames, when the rendering would hang, with the mali only coming back several seconds later. After a bit of trying around, i gave the GP (vertex shader) a bit more space for its tile heap. This time it ran for about 800 frames before the same thing happened. I doubled the tile-heap again, and it ran all the way through!The evening before i had hoped that i would get about 20fps out of this hardware. This already was a pretty cocky and arrogant guess, as the binary driver ran this demo at about 47.3fps, but i felt confident that the hardware had little to hide. And then the demo ran through, and produced a number.30.5fpsWay beyond my wildest dreams. Almost 65% of the performance of the binary driver. Un-be-liev-ab-le. And this was with plain sequential job handling. Start a GP job, wait for it to finish, then start the PP job, wait for it to finish, then flip. 30.5fps still! Madness!I had two weeks left for FOSDEM, so i had a choice, either add input support and invite someone from the public to come and play before the audience, or, optimize until we beat the binary driver. The framerate of the first pass decided that, optimization it was. I had a good benchmark, and only a third of the performance needed to be found, and most of the corners for that extra performance were known.My first optimization was to tackle the PP polygon list block access pattern. During my previous talk at FOSDEM, i explained that this was the only bit I found that might be IP encumbered. In the meantime, over the weekly beers with Michael Matz, the SuSE Labs toolchain lead, i had learned that there is thing called the "hilbert space filling curve". Thanks Matz, that was worth about ~2.2fps. I benchmarked another few patterns: two level hilbert (inside plb block, and out), and the non-rotated hilbert pattern that is used for the textures. None would give us the same performance as the hilbert curve.Building with -O3 then gave us another 1.5fps. Passing vec2s between the shaders gave us 0.3fps. It was time to put in proper interleaved job handling. With the help of Marcus Meissner (the SuSE Security lead), an ioctl struct sizing issue was found for the job wait thread. This fixed the reliability issues with threading on the r3p0 kernel of linux-sunxi. (ARM! Stable kernel interfaces now!) But thanks Marcus, as proper threading and interleaved job handling put me at 40.7 fps!And then i got stuck. I only had 40.7fps and knew nothing that could account for such a big gap in performance. I tried a few things left and right, but nothing... I then decided to port q3a to GLES2 (with the loss of alphafunc and buggered up lamps as a result) to see whether our issue was with the compiled versus hand-coded shader. But I quickly ran into an issue with multi-texture program state tracking, which was curious, as the lima code was logically the same. Once this was fixed the GLES2 port ran at about 47.6fps, slightly faster than GLES1, which i think might be because of the lack of alphafunc.Immediately after that i ported the multi-texture state tracking fix to the limare GLimp, but i sadly got no change in framerate out of it. Strangely, it seemed like there was no multitexturing going as my debugging printfs were not being triggered. I then noticed the flag for telling Q3A that our GL implementation supports multitexturing. Bang. 46.7fps. I simply couldn't believe how stupid that was. If that had been correct on the first run, i would've hit above 75% of the framerate, how insane would that have been :)For the final 1.5fps, which put us at 48.2fps, i added a third frame, this while only rendering out to two framebuffers. Job done!Adding a fourth frame did not improve numbers, and i left some minute cpu usage and memory usage optimizations untouched. We are faster than the binary driver, while employing no tricks. We know what we need to know about this chip and there is nothing left to prove with Q3A performance.The numbers.The fact that we are slightly faster is actually normal. We do not have to adhere to the OpenGLES standard, we can do without a lot of the checking that a proper driver normally needs to do. This is why the goal was not to match the binary driver's performance, but to beat it, which is exactly what we achieved. From some less PP and CPU bound programs, like the spinning cubes, it does seem that we are more aggressive with scheduling though.Now let's look at some numbers. Here is the end of the timedemo log for the binary driver, on an Allwinner A10 (single cortex a8, at 1GHz), with a Mali-400MP1 at 320MHz, rendering to a 1024x600 LCD, with framerate printing enabled: THEINDIGO^7 hit the fraglimit. marty^7 was melted by THEINDIGO^7's plasmagun 1260 frames 27.3 seconds 46.2 fps 10.0/21.6/50.0/5.6 ms ----- CL_Shutdown ----- RE_Shutdown( 1 ) -----------------------And here is the end of the timedemo log for the limare port: THEINDIGO^7 hit the fraglimit. marty^7 was melted by THEINDIGO^7's plasmagun ]64f in 1.313632s: 48.719887 fps (1280 at 39.473158 fps) 1260 frames 26.7 seconds 47.2 fps 9.0/21.2/74.0/5.6 ms ----- CL_Shutdown ----- RE_Shutdown( 1 ) ]Max frame memory used: 2731/4096kB Auxiliary memory used: 13846/16384kB Total jobs time: 32.723190 seconds GP job time: 2.075425 seconds PP job time: 39.921429 seconds -----------------------Looking at the numbers from the limare driver, my two render threads are seriously overcommitted on the fragment shader (PP). We really are fully fragment shader bound, which is not surprising, as we only have a single fragment shader. Our GP is sitting idle most of the time.It does seem promising for a quad core mali though. I will now get myself a quad-core A9 SoC, and put that one through its paces. My feeling is that there we will either hit a wall with memory bandwidth or with the CPU, as q3a is single threaded. Since limare does not yet support multiple fragment shaders the last remaining big unknown will get solved too.Another interesting number is the maximum frame time. 50.0ms for the binary driver, versus 74.0ms for limare. My theory there is that i am scheduling differently than the original driver and that we get hit by us overcommitting the fragment shader. Wait and see whether this difference in scheduling will improve or worsen the numbers on the potentially 4 times faster SoC. We will not be context switching anymore with our render threads, and we will no longer be limited by the fragment shader. This should then decide whether another scheme should be picked or not.Once we fix up the Allwinner A10 display engine, and can reliably sync to refresh rate, this difference in job scheduling should become mostly irrelevant.The star: the mali by falanx.In the previous section i was mostly talking about the strategy of scheduling GP and PP jobs, of which one tends to have 1 of each per frame. Performance optimization is a very high level problem on the mali, which is a luxury. On mali we do not need to bother with highly specific command queue patterns which most optimally use the available resources, which then ends up being SoC and board specific. We are as fast as the original driver without any trickery, and this has absolutely nothing to do with my supposed ability as a hacker. The credit fully goes to the design of the mali. There is simply no random madness with the mali. This chip makes sense.The mali is the correct mix of the sane and the insane. All the real optimization is baked into the hardware design. The vertex shader is that insane for a reason. There is none of that "We can fix it in software" bullshit going on. The mali just is this fast. And after 20 months of throwing things at the mali, i still have not succeeded in getting the mali to hard or soft lockup the machine. Absolutely amazing.When i was pretty much the only open source graphics developer who was pushing display support and modesetting forwards, I often had to hear that modesetting was easy, and that 3d is insane. The mali proves this absolutely wrong. Modesetting is a very complex problem to solve correctly, with an almost endless set of combinations that requires very good insight and the ability to properly structure things. If you fail to structure correctly, you have absolutely no chance of satisfying 99.9% of your users, you'll be lucky if you satisfy 60%. Compared to modesetting, 3D is clearly delineated, and it is a vastly more overseeable and managable problem... Provided that your hardware is sane.The end of the 90s was an absolute bloodbath for graphics hardware vendors with just a few, suddenly big, companies surviving. That's exactly when a few Norwegian demo-sceners, at the Trondheim University, decided that they would do 3D vastly better than those survivors and they formed a company to do so, called Falanx. It must've seemed like suicide, and I am very certain that pretty much everybody declared them absolutely insane (like engadget did). Now, 12 years later, seeing what came out of that, I must say that I have to agree. Falanx was indeed insane, but it was that special kind of insanity that we call pure genius.You crazy demo-sceners. You rock, and let this Q3a port be my salute to you. [Less]

Linux kernel 3.8 comes with a new ‘cdc-mbim‘ driver… let’s see what all this is about…   What is MBIM? The Mobile Interface Broadband Model (MBIM) is a new standard developed by the USB Implementers Forum, specifically designed for high speed mobile ... [More] broadband modem devices. This new USB networking subclass defines two separate new features: A new MBIM USB device model, providing multiple IP connections over a single USB interface, and without the need of 802.3 frames (as was the case with ECM and NCM) A new MBIM control protocol to talk to modem devices   MBIM message types The protocol defines different message types with different formats. Some of them are used to establish the channel of communication with the modem: Open Message (Host->Modem): Initialization request. Open Done Message (Host<-Modem): Initialization response. Close Message (Host->Modem): Close request. Close Done Message (Host<-Modem): Close response. Some of the messages are used to report errors in the protocol; which may be sent either from the host or from the modem: Host Error Message (Host->Modem): Host-reported error. Modem Error Message (Host<-Modem): Modem-reported error. And finally, some messages provide access to the different CIDs (Command IDs) defined in each Service. Command Message (Host->Modem): Request of a given command. Command Done Message (Host<-Modem): Response to a given command. Indication Message (Host<-Modem): Unsolicited messages sent by the modem. These last three messages support protocol-defined fragmentation. If the sender of the message finds out that the message is longer than the maximum control transfer size defined when the communication channel was opened (with an Open Message), it will be able to split it into sorted chunks and send them one by one over the wire. Each of these fragments specify the total amount of fragments expected, as well as the order in the sequence. The receiver of the fragments will therefore need to wait for all fragments to arrive – which should arrive in order – before processing the message.   MBIM services The protocol defines a basic set of different Services: Basic Connect: Which provides the support for basic IP connectivity SMS: SMS messaging USSD: Unstructured Supplementary Service Data Phonebook: Handling contacts and such STK: SIM toolkit Authentication Device Service Stream Only the Basic Connect one is mandatory in every MBIM device; others are optional. Vendors or even Network Operators can also extend the functionality of the device with other services; for example to support other protocols embedded within MBIM (e.g. QMI or AT within MBIM); or just to provide specific new features.   MBIM commands For each service, MBIM defines a set of Commands (CIDs); and each command can then be divided into 3 actions: “Set“: An user-requested action to change the modem state or configuration “Query“: An user-requested action to query the modem state or configuration “Notification“: An unsolicited report of the modem state or configuration Not every action is supported by every command. For example, the “Device Caps” command in the “Basic Connect” service only supports the “Query” action, while the “Radio State” command of the same service supports all “Set“, “Query” and “Notification“. But how does this match with the message types defined before? Host-created “Set” and “Query” requests are sent using “Command Messages“. Modem-created “Set” and “Query” responses are sent using “Command Done Messages“. Modem-created “Notifications” are sent using “Indication Messages“.   MBIM basic types The protocol not only defines which action is supported in each command; it also defines the contents of the request, response and indication messages. The contents of each message are composed of collections of basic types defined by the protocol: Unsigned 32bit integers: Even for the most simple values (e.g. booleans), little-endian 32 bit unsigned integers are used. Strings: UTF-16LE encoded strings are always used. UUIDs: The protocol defines a special 16-byte-long UUID type, e.g. to define Service IDs Arrays: Collection of N values of a given basic type. Structs: Sequence of other basic types, given in a specific order. As you can see, there is not much effort (none, actually) into making the protocol efficient in terms of overhead introduced; more than half of the bytes in each message will very likely end up being NUL bytes. Also, it is assured that each field within a message is aligned in a 32bit boundary, which makes it easier to read independent fields directly from the binary stream.   How does this compare to QMI? There are quite some differences between this protocol and QMI. To name a few: Less basic types in MBIM, specially regarding signed/unsigned integers. QMI defines many more integer types, of different sizes and with different sign. Basic strings are given in ASCII in QMI Struct types are re-used in MBIM, as opposed to QMI, where each TLV would define the struct contents as it needed. There is no ‘client allocation’ needed in MBIM, i.e. the process opening the MBIM port doesn’t need to allocate clients for the different services. Fragmentation is built-in in the MBIM protocol; QMI required special TLVs and logic to handle messages that may be longer than the standard message size (e.g. when transferring the PRL list). Binary representation of the message is completely different. In QMI you would have a list of TLVs, one after the other. In MBIM, the contents of the message are split into two different sections: one which contains the fixed-size values and one for the variable-size values. For example, a string in MBIM is defined by two values in the fixed-size region (offset and size), while the real string data is within the variable-size section.   libmbim The ‘libmbim‘ library is an attempt to write a protocol support library, as previously done with ‘libqmi‘. The current codebase, GLib/GObject/GIO based, is pretty similar to what libqmi provided, with a ‘MbimDevice‘ GObject to handle the communication through the /dev/cdc-wdm port, as well as ‘MbimMessage‘ types to handle the creation of commands. Given that there is no need for client allocations in MBIM, there is no ‘MbimClient‘ object needed. Also, given that the contents of each message are pre-defined, it wasn’t considered the need of input and output ‘bundles’ to handle collections of TLVs, as done in libqmi. Fragmentation of incoming/outgoing messages is handled internally by the ‘MbimDevice‘, which is a nice thing to have, as it simplifies the usage of the API. The user just creates a message, as long as it needs it to be, and the ‘MbimDevice‘ will take care of splitting it into fragments. When receiving a message, the user will also receive already the full message, once all fragments have been combined internally. The messages and the services are defined in a JSON dictionary, and as with libqmi, all the message handling code is auto-generated from there. The capabilities of the mbim-codegen are still not in pair with those in qmi-codegen yet, though. The generator doesn’t support e.g. “Set” requests with parameters, or “Indication” messages. As previously said, this currently is a proof-of-concept, someday we’ll support all those properly.   mbimcli The project comes with a command line utility (mbimcli), which allows (will allow) running “Get” or “Set” commands directly from the shell. There aren’t many supported commands yet, so I cannot show many more examples than this one: $ sudo mbimcli \     -d /dev/cdc-wdm1 \     --basic-connect-query-subscriber-ready-status [/dev/cdc-wdm1] Subscriber ready status retrieved:       Ready state: 'device-locked'     Subscriber ID: 'unknown'         SIM ICCID: '984310311520086950F1'        Ready info: 'unknown' Telephone numbers: '' Hint: Using --verbose will show you the raw binary message contents!   Where do I get it? The ‘libmbim’ library and the ‘mbimcli’ utility can be found in the following Lanedo-maintained gitorious repository: git: https://gitorious.org/lanedo/libmbim   There is already a request to host this project in the freedesktop.org infrastructure, so it may end up getting moved there at some point.   Help! Contribute! Sponsor! This development was kindly sponsored by Lanedo GmbH. If you want to help, or sponsor further development in libmbim, mbimcli or the ModemManager integration, just let us know! Filed under: FreeDesktop Planet, GNOME Planet, Lanedo Planet, Planets Tagged: freedesktop, libmbim, libqmi, MBIM, ModemManager, QMI [Less]

Unbeknownst to most, last week was a pretty big week for open-source graphics drivers... and I'm not referring to all the presentations at FOSDEM. Intel and the Mesa community made good on my bold claim at SIGGRAPH 2012, and we submitted OpenGL ES ... [More] 3.0 conformance results for Ivy Bridge GPUs on the Mesa 9.1 release branch last Tuesday. So far, only two other companies have made submissions, one before and one after ours. This is a really big deal for both Intel and Mesa! When was the last time either produced a hardware driver within a reasonable amount of time after the spec was released? I'm not sure that Mesa has ever done that, and I believe it was around OpenGL 1.3 for Intel... and now we're one of the first... Once the 30-day review period has passed (assuming there are no faults found with our submission), we'll be listed in the conformant products list. Watch this space for more details... [Less]

FOSDEM was great as ever, despite that I've managed to grab a bit too much attention from my management by spilling the Intel OTC gfx driver team headcount a bit ;-) Anyway, for those who missed my presentation, I've uploaded the slides (with that ... [More] embarrassing typo fixed in one headline). Phoronix should upload a video of the talk soon, I'll add a link as soon as that happens. [Less]

I have a Logitech DiNovo Mini (combined keyboard & touchpad), which at first worked just fine on my Gentoo laptop, Asus G50V, using the laptop's built-in bluetooth adapter, Bluez major version 4 (4.101-r5 today), and manual connection. Then I ... [More] tried to connect the DiNovo to other devices, both without and with the USB-bluetooth-dongle that came with the DiNovo. Then I wanted it back to my laptop. There was a time when it worked only if I temporarily removed the battery from DiNovo. In the end, after several weeks if not months, it did not work anymore, at all. Blindly poking around, I now found how to fix it.The DiNovo showed a green light, saying it got a connection, but on the laptop, all I could see was the device appearing and very soon disappearing in udev (confirmed with udevadm monitor). I tried to pair it again, many times, and while the pairing seemed to succeed, the device just did not work. I also installed blueman, which indicated the same: when I touched the DiNovo, it connected, and was immediately disconnected. In the system log I got:bluetoothd[280]: Refusing input device connect: Operation already in progress (114)bluetoothd[280]: Refusing connection from ##:##:##:##:##:##: setup in progress(bluetoothd:280): GLib-WARNING **: Invalid file descriptor.Ok, so is it trying to connect twice for some odd reason? Where is the state kept? Could I manually fix it?Apparently, I could. In the /var/lib/bluetooth/*/ directory I saw several files that seemed to be about the bluetooth settings on my Gentoo. Not knowing anything about how Bluez works, I looked at the files there, to see if I could spot something suspicious. Luckily they were all plain-enough text files, so I did spot something.The file /var/lib/bluetooth/*/spd had two lines with my DiNovo's device address on it. The first line was a long one, the second line short. Not knowing what I'm doing, I stopped the bluetooth service, removed the short line, and restarted the bluetooth service. Like magic, the DiNovo started working again, connecting automatically. No errors in the system log anymore, either.I have not used the DiNovo much after the repair yet, remains to be seen if I broke anything, but so far so good. Apparently when I was playing around with the DiNovo, somehow that file got a second entry for the same device, and caused malfunction. Is it my fault or a bug, I do not know. Googling did not give any helpful hints on solving this, so I am recording this note here, hoping it helps someone.-- A note, barely readable, scratched with a broken SD-card on the wall of a passageway in the huge, monster crawling dungeon they call the Intternets. [Less]

In a couple of hours, I'll be taking the train and heading to Brussels for FOSDEM. I've lost counts of how many FOSDEM I've attended, which is probably a good indication of how great the event is! As usual, this will be a good place to catch up ... [More] with friends, but also to talk with tons of different people about so many topics. If you want to chat about OpenStack, SUSE Cloud, openSUSE or GNOME, I'll be glad to join you. The schedule is quite packed, but from what I can tell so far, I'll be sitting in the cloud devroom on Sunday (don't hesitate to join in order to learn about what's happening in the OpenStack world!). Oh, I'll also give a talk in Janson about challenges that the GNOME project is facing, just before the closing keynote. And no, I won't have my blue hat, so you'll need to find another way to catch me (hint: I have a SUSE backpack nowadays) ;-) [Less]

In the past couple of weeks, apart from reviewing very many patches for gnome-control-center (especially for new and re-designed panels), I've been working on updating the power management handling in GNOME.Test suiteThe first change is that we have ... [More] a test suite (currently with 15 separate tests) to test interaction between gnome-settings-daemon's power management and various session and system components. This is thanks to Martin Pitt, and his work on python-dbusmock.We'll try and add new tests as bug reports come in to avoid regressions, although some cases will remain untested because of limitations in our logging. All clearScreensaver and backlight interactionWith gnome-shell becoming the sole screensaver (after the removal of fallback mode, and the obsoletion of gnome-screensaver), we've been able to streamline the code handling the various screen backlight power levels.Your screen will now turn off as soon as the screensaver kicks in, moving your mouse in the screensaver will turn it back on for 20 seconds before turning off again, and when to dim (if you've chosen so) is dependent on whether you're on battery or not, and the default idle time (eg. if your screen turns off after 5 minutes of inactivity, the screen will dim after 4). This makes the behaviour more consistent, and predictable, compared to the mish-mash of settings we had before, where some delays were available for change in the UI, and others only through GSettings or gnome-tweak-tool.Those constants are separate from the code, and exported to the test suite so they are flexible and can be changed if the behaviour doesn't exactly match what users are expecting.The other change relating to that, is that the screen shield will now always pop down when the screensaver kicks in (thanks to Giovanni for the gnome-shell work). This doesn't mean that you'll have to enter your password each time, but only after the "lock delay" if you've set one.We've also added a number of nice touches, like the screen turning back on for a short period when you plug or unplug your laptop, made sure that your laptop screen gets turned off and your session locked when closing the lid and turn off the backlight for machines where suspend causes the backlight to come back on temporarily (as seen on MacBooks).Very very idleWe've also added a long-requested feature: the ability to force logout after a period of idle. This is useful in kiosk and computer lab situations, and is only available through GSettings. As we've added support for this feature (warning prior to logging out, with the screen turning on for a couple of seconds when the warning shows up), we've realised that the infrastructure is the same for automatic suspend/hibernate situation. This means I expect to change the default "long idle" behaviour to suspending. This will still be changeable in the Power preferences. This should land after 3.7.5, and don't worry, we'll make this change very visible in the release notes :)*I* am not suspending by defaultInhibitBut you don't want to suspend, you really don't.GNOME supports the draft FreeDesktop "Idle inhibition" specification, as implemented by KDE, which hopefully means that more third-party applications should start behaving better when playing back films, in presentation mode, or for large overnight downloads. This should hopefully get out of draft status before the GNOME 3.8 release.We also have a gnome-session-inhibit tool available in gnome-session for your scripting needs.Colophon All the changes mentioned should be available in GNOME 3.7.5, and I will be available to take complaints at FOSDEM this week-end. [Less]