Some of you may have spotted that there is a new Raspbian release available for download. For most people, this is primarily updates and bug fixes to the existing Jessie image – but there’s one exciting new feature that might be of interest to some people…

But before we get to that, here’s a summary of the other changes.

New versions of applications

There are new versions of many of the standard applications.

Sonic Pi is now at version 2.9. A full list of changes can be found in the History section of the Info window in Sonic Pi, but the highlights include two new effects functions, a new logging system, and the inclusion of all of Sam Aaron’s articles for The Magpi magazine as part of the online tutorials.

Scratch is now at version 20160115. This has improved sound input capabilities, support for the CamJam EduKit 3 robotics board, basic PWM support in the GPIO server, and various improvements to the display, including font scaling.

Mathematica is now at version 10.3. This adds support for a larger set of the functionality detailed in Stephen Wolfram’s new “Elementary Introduction to the Wolfram Language” book. It also supports the use of the Sense HAT, adds interfacing to Arduino, and includes many new Mathematica functions.

Node-RED is now at version 12.5 – this adds no significant new functionality, but fixes a number of bugs and contains some internal performance improvements.

New versions of libraries

WiringPi has been updated to version 2.31, which allows GPIO pins to be accessed from applications that use the library without needing to use sudo. For more details, see the WiringPi website.

The RPi.GPIO Python library has been updated to version 0.6.1 which includes some bug fixes which affected the new GPIO Zero library.

The Java platform included has been updated to version 8, update 65.

Bug fixes

The volume/audio device icon on the taskbar is now compatible with a wider range of USB audio devices – people reported that it was impossible to set some USB sound devices as the default output. Due to the way the ALSA system works, it is very difficult to make this completely infallible, but the new version should work with a much wider selection of devices than before.

The Main Menu editor now allows new menus to be created. In earlier versions, due to an issue with the way the LXDE desktop environment interpreted its configuration files, creating a new menu caused all other menus to be hidden – this should now work correctly.

The GUI Raspberry Pi Configuration and command-line raspi-config applications now offer the correct overclocking options on all Pi 1, Pi 2 and Pi Zero boards. There are also some updated language translations submitted by the community – many thanks to the translators!

The Wastebasket is now consistently named as such everywhere when the desktop is set to British English. (It previously had a wide selection of names in different places, including Trash and Rubbish Bin…)

The ping command no longer requires sudo.

One more thing…

We hope the above changes are useful, but Raspbian will still look pretty much the same as it did for the last release in November. But we have been working on one other thing behind the scenes for this release: this won’t be of interest to most users, but for some, we hope it will be very useful.

In this release we are shipping an experimental OpenGL driver for the desktop which uses the GPU to provide hardware acceleration. This is turned off by default – if you want to enable it, you can find it in the command-line version of raspi-config, under Advanced Options->GL Driver. Due to memory requirements, this will not work on Pi 1 or Pi Zero boards – it is solely for Pi 2. (raspi-config will only allow it to be enabled on a Pi 2; be warned that if you enable it on a Pi 2 and then move that SD card into a Pi 1 or Pi Zero, the Pi will not boot.)

If you don’t use this option, the desktop does have OpenGL support, but it uses a very slow software renderer, which makes all but the most basic OpenGL applications pretty much unusable. The hardware-accelerated version is much faster, and makes some quite decent OpenGL games playable on the Pi.

As a quick demonstration of the effect of the driver, try installing the mesa-utils package with

sudo apt-get install mesa-utils

This installs a simple OpenGL demo program called glxgears which shows three rotating gear-wheels. To run it, type

glxgears

With the standard software renderer, this runs at around 23 frames per second, flickers a lot, and doesn’t actually show the correct colours. If you try it again with the new driver enabled, it runs at the screen refresh rate of 60 fps, with no flicker and the correct colours.

Rotating gears are all very well, but they aren’t that exciting, are they? So how about some actual games? One that is popular in the office is Neverball – try

sudo apt-get install neverball

This barely runs at all under the software renderer, but is quite slick and playable with the new driver.

Or try Oolite, which looks quite similar to another game that those of us of a certain age remember fondly.

sudo apt-get install oolite

There are various other OpenGL games and applications available in apt – to find them, try

apt-cache search opengl

Bear in mind that this is an experimental release of the driver which we are making available to the community as a public beta test; it is still slightly unstable, there will inevitably be some graphic glitches, and you shouldn’t expect every OpenGL program to run perfectly. It also has some side effects, notably in terms of making small changes to the way normal windows and menus are displayed. For this reason, we’d advise only enabling the driver if you know that it is going to be useful for some specific program you are using; if you’re not sure whether or not you should be using it, you probably shouldn’t be!

Also note, this experimental driver may break Raspberry Pi Camera and video playback support, and perhaps other GPU functionality.

How do I get it?

A full image and a NOOBS installer are available from the Downloads page on this website.

If you are running the current Jessie image, it can be updated to the new version by running

I think Raspbian is still shipping an openarena linking against the closed driver. I’ve done a bunch of testing with stock openarena, but it’s slower than the custom ES build because we keep having to translate their 4-byte index buffers to 2-byte.

Darren, sorry but no ultrasonic sensor support yet. It’s actually quite tricky to do well in the scratch framework for sensors. You *can* just use a couple of gpio pins, a timer black and maths etc but it has dreadful resolution. I’m trying to work out a clean way to handle it.

Small request for a future tweak. Any chance you could make the mouse double click speed in the desktop environment configurable? My kids find it quite difficult to do it quick enough at the moment and I can’t find a way to change the speed.

there is a hidden file named “.gtkrc-2.0” in your home directory. So if it does not exist, create it. If it does exit, read it before you proceed — it may advise you to use “.gtkrc-2.0.mine” instead.
Type these commands in Terminal:

sudo nano ~/.gtkrc-2.0

Add the following line:

gtk-double-click-time=1000

Press Ctrl – X, y and enter to save and quit the editor.
restart your Raspberry Pi for it to take effect.

When have you deployed it? Since the weekend a dist-upgrade will break my Pi2. Libc6 has not all required dependencies and I am not able to do apt-get upgrade or dist-upgrade any longer, because the config files are not containing proper dependencies.

I moved just before this to a larger SD-Card because the 8GB was to small to compile opencv. So hardware accelatered OpenGL support sounds great for OpenCV. Please add OpenCV 3.1 as a package to jessie. I don’t want to learn how hard installing is, I want to learn how to use it for face and object recognition ;-)

I while ago there was a suggestion that it might be possible make a minimal opensource version of the blob that is required to boot the Pi [1]. Has there been any progress on this? It would be great if Pi could be free enough to bounce up a few levels on the FSF single board computer list [2] and be recommended by projects like freedombox [3].

Micha, I assume that you backed up you card before using this “experimental” OpenGL driver? If you did not then at least you’ve learned one valuable lesson today. Of course this may not be much help in your current situation but if it reminds others to backup before trying something classed as “experimental” you might take solace from the fact that you have taken one for the team. Thanks for the reminder.
If you did back up your card then revert to it and wait for the OpenGL driver to be less experimental.

If you have an SD card reader on another computer use that to mount the boot partition and edit the config.txt file. Find the line:
dtoverlay=vc4-kms-v3d
and make sure it has a # at the start,
#dtoverlay=vc4-kms-v3d
to disable it.

Apologies – I’ve just discovered that when I wrote the board detection routines in raspi-config, I neglected to take into consideration that some boards will have their warranty bits set.

I’ve pushed a change into raspi-config, but it’ll take a while to appear on apt. In the meantime, you can edit /usr/bin/raspi-config by hand – replace the three functions called is_pione, is_pitwo and is_pizero at the top of the file with the following:

Fantastic!! I run a Pi2 on a boat with navigation software (openCPN) which can use openGL, a massive improvement!!!
One thing, when first installed i had display problems with the screen flipping between a rainbow pattern and normal. This turned out to be a power issue, measuring the voltage at the Pi itself it was low, so cranking up the voltage a bit on the variable supply I use it’s all good now, plus the FPS increased in the nav software. Thanks for this :)

Ok, back on the Pi now after editing the configfile in boot-dir on another pc…backup? Of course^^

However, I do not get it to work.

Before I started here I’ve done an update,upgrade+dist-upgrade.. Now after the blackscreen I installed the 2 missing things
sudo apt-get install xcompmgr libgl1-mesa-dri – when I reboot, I’ll get a blackscreen after the coloured bootup-screen.

The GPU shouldn’t need much memory, but the CPU does need a large chunk while running the new driver. From memory, allocating more than about 280 MB to the GPU will prevent the Pi from booting with the new driver running. Feel free to experiment with these, but our recommendation is to keep GPU memory lower rather than higher.

There are three changes which raspi-config makes when the driver is enabled.

1. The vc4-kms-v3d overlay is added in config.txt
2. The composition manager xcompmgr is started at desktop start
3. The fbturbo video driver is disabled by deleting /usr/share/X11/xorg.conf.d/99-fbturbo.conf

All three changes need to be made to enable the driver; all three need to be undone to disable it – this is why it is a raspi-config option rather than something which we are encouraging people to do manually. If you are having to recover a trashed system, make sure you undo all three – look at the function set_gldriver in raspi-config for details.

1. ok
2. dont know as I see nothing – but as I have installed it, I assume it works
3. I now have a look at this manually

Recovering my blackscreen was easy with a second pc…but it does not change the fact that I am still not able to get it to work…I only g2t a blackscreen when activating the relating text in config.txt and reboot, whatever I do.

I see no power-symbol, but to clearify out thats not the fault I pulled out everything from usb, without change. I wll now have a look at that fb-stuff relating to point 3 manually…..

I’m not sure if this is your problem but mine was working fine, then I changed the memory split from 128MB to 256MB and the Pi booted to a blank screen. I changed it back to 128MB and it booted to the desktop without a problem.

Yes, as I mentioned in a comment above, the new driver requires a large chunk of CPU memory. I think in my testing the breaking point was that allocating around 280MB of GPU memory would result in failure to boot. (The driver allocates a 256MB buffer of system memory for its own use; if there isn’t enough memory left available after the GPU allocation has been made, the driver is unable to allocate enough memory for its own use and dies.)

Solved, BoB LeSuer found the solution a few postings after this…it is necessary to boot directly to GUI.
It has the wrong screensize/resolution and is unusable here cause the bar and some icons are missing, but I see my background at all.

I think the open source driver should eventually become equivalent to the proprietary one in terms of speed and efficiency. It might take another two years though. The closed source driver doesn’t do much but when it can be used it’s probably faster.

I did a sudo apt-get update && sudo apt-get dist-upgrade without any issues. Installed the other items, went into raspi-config and enabled the driver, rebooted.

I do see periodically a black screen when its trying to render some 3d, like oolite. Basically the screen will go dark and the little rainbow square will appear in the top right hand corner. Its as if the Raspi isnt getting enough power when running 3d apps?

Ive tried this with a PSU purchased from Adafruit and also when connected to a Motorola Atrix Lapdock, and I get the same issue.

The new driver is more power-hungry than the standard software renderer, and I have seen similar issues in testing. I have a third-party USB cable with an inline switch between my Pi and the PSU, and I was seeing similar effects to those you describe with that in the circuit and with an external USB audio device plugged in. Make sure you disconnect any unused USB power sinks, ensure you are using a good-quality USB PSU, and get rid of any inline switches (like the one I was using…)

Yeah I switched to another USB psu that I had lying around and Im no longer getting black screens or the rainbow square appearing at the top RHS. Now to source a usb power cable without an inline switch.

Anyway. I don’t see the option to enable GL in raspi-config. Even after “update this tool to the newest version” nothing show up. I did apt-get update, followed bei upgrade and installed the mesa stuff beforehand but still nothing.

Link to Tweet showing standard desktop with a program running full screen.
The piece at the bottom looks like the Status Bar is filling the rest of the screen.
Also showing I hard set the resolution to match the monitor.https://twitter.com/winkleink/status/697089741947277316

Love that OpenGL works so well. Would love to have it fill the screen.

For testing I moved the panel to the bottom and changed it’s colour to red.
The panel moved and changed colour, but also everything from the panel to the bottom of the screen changed to red.
So, the whole screen is being controlled and updated, but it’s not being made available for the mouse and applications

I did update, upgrade, dist-upgrade + rpi-update and selected update to newest version of this tool in raspi-config before commenting here. The option was still not available … and yes ist it a raspi2, memory-split is set to 256 but I tried with 128 as well.

All our devices (including remote ones) are loaded with Wheezy. We don’t want to do distribution upgrade since we don’t want to risk bricking our devices but we do small maintenance updates or some software installations. So if we can install the driver without doing the big distribution update, we would prefer to do that.

How hard is it to get an answer to a simple question? Just tell me if it can be installed to Wheezy and that’s it, that was my question. If you don’t know then don’t fill here with unrelated comments. I didn’t ask your “valuable” opinion on how to handle the update process of our devices. Do you know our product? Do you know our testing process? Do you know about our company strategy? Maybe OpenGL is so key and will provide so much benefit that we will take the risk of bricking our devices? Maybe out of tens of test installations OpenGL driver will not brick any Raspbian Wheezy devices so we will take that small risk?

Again I ask “just out of curiosity” is this new OpenGL driver installable to Raspbian Wheezy or do we need to upgrade to Raspbian Jessie?

This so awesome. Seeing glxgears running on the Pi at 50 odd frames per second and using only a few percent CPU takes me back to the day I first got accelerated OpenGl running on Linux. Using a shiny new 3DFX Voodoo graphics card back in 1999.

pi@raspberrypi:~ $ sudo apt-get install neverball
Reading package lists… Done
Building dependency tree
Reading state information… Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
neverball : Depends: libsdl2-2.0-0 (>= 2.0.0) but it is not going to be installed
Depends: libsdl2-ttf-2.0-0 (>= 2.0.0) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

For what it’s worth, if my RPi is set to boot to console, then I get a black screen (following the full-screen rainbow splash). If I have set to boot to the GUI, then the driver seems to behave properly.

AHH, thats the solution…the reason why I got a blackscreen all the time when activated GL!
Checked it, if I turn the Pi to boot directly to Lxde, I got a visible screen. The screen still is total garbage, half is missing and the resolution was totally wrong…but I could see something. Still needs lots of work, but in general nice to see that the driver is functional at all!

However, whats also impressing me much in this update is that there is a new Mathematica-version…really good

I have noticed that Omxplayer no longer works with OpenGL turned on. Is this expected?

I’ve also noticed other software seems to be running much more slowly e.g. I use Geany with several tabs open to edit source code. When switching tabs you can visibly see it drawing the text down the screen but if I turn OpenGL off it is back to full speed again. I realise this is experimental and maybe I am expecting too much at this early time?

This is all based on Eric Anholt’s driver. From his blog
(http://anholt.livejournal.com/45752.html)
“They want to make sure we don’t regress functionality, obviously, and there are some big chunks of work left to do: HDMI audio support, video overlays, and integration of the vc4 driver with the camera and video decode support come time mind”

OMXPlayer acceleration on a Pi 2 in Kodi, for me, has always been easily broken. Simply play a video in the background (Background music visualization/video player on Home screen) and start scrolling one of your media libraries. Soon you’ll see the posters or banners start to vanish and the scrolling gets choppy or just plain freezes. ReloadSkin() brings things back to life but it’s a sorry state if you need OMXPlayer to run streaming media off the web where audio is sometimes corrupted into silence as well, depending on the source.

So hearing that OMXPlayer doesn’t like this new driver isn’t all that surprising.

Ok, Im quite dumb about 3D so, this means games/apps written with opengl need can now be compiled to the Pi?
For example pyopengl and such libs can now support a game like Frets On Fire? (it’s for opengl)
and the openglES? what’s de difference in this case now?

Bottom line is: Can I compile/run games natively made to opengl (not openglES) hardware?

@Celso – OpenGL is the full version of the standard meant to operate on workstations and other systems primarily designed to generate the highest-performance 3D graphics. OpenGLES is somewhat of a subset with some reductions in functionality, missing features, as well as how the APIs are called. It’s meant for mobile devices with a system-on-a-chip (SoC) that doesn’t have nearly as much GPU horsepower as workstations and 3D graphics rendering engines/farms have. The VideoCore IV GPU in the Pii is one of the most powerful in 32-bit SoCs, so it’s very exciting to see that they’ve managed to get OpenGL running on it, especially integrated with the desktop (well, to a degree, as it’s a bit buggy on the lower part of the desktop, apparently).

OpenGLES applications should still run as different libraries are referenced and linked with during builds. The demos in /opt/vc/src/hello_pi are built using OpenGLES and still build and run as before. For those not familiar, type “./rebuild.sh” without the quote marks from that directory. Then, for example, cd into hello_triangle and type “./hello_triangle.bin” (without quotes), and marvel at a rotating cube with images mapped onto the six sides.

Which version of OpenGL? Does it mean that we can look forward to Vulkan when it gets released? (Wikipedia on Vulkan: “Initial specifications state that Vulkan will work on hardware that currently supports OpenGL ES 3.1 or OpenGL 4.X and up”)

It’s great to see accelerated OpenGL – but it would be better to mention enabling it completely KILLS ALL CAMERA SUPPORT, as well as accelerated video via omxplayer…. I realise its an early release, but the blog above ONLY mentions “minor graphics glitches” – not core features stopping working !!

Grumbling aside – I’m happy to use the OpenGl support on a different SD card as needed, now I know the llimitations. No doubt future updates will improve.

It’s EXPERIMENTAL. Of course there will be bound to be bugs and compatibility. That is why it is disabled by default and requires people to manually enable it. The point being for advanced users to hopefully test it out with this announcement and *kindly* report issues, since there are thousands of software and possible configurations out there – too many to test completely by a small group of developers giving you free software. Anyone who requires to maintain a stable working system should NOT be enabling this. Otherwise let the rest of us help out on putting this great new feature through its paces with constructive comments, so as to root out bugs and make the most awesome low-cost single board 3D renderer. [Mod edited for grumpiness.]

I use the Atari Stella emulator and it worked brilliantly in Wheezy. When Jessie was released it was broken and could only be started in ‘software mode’ which was unuseable. This new driver has enabled me to use it again at full speed BUT only in a small window – when set to full screen it slows down terribly. I have looked at the settings and enabled OpenGL mode but it still won’t work properly full screen. I wonder why all was perfect in Wheezy … ?

When I first read that there was a new OpenGL driver I thought, big deal, the GPU has been running OpenGLES since Day One, who cares? Then I was reading through the comments and realized that they hadn’t accidentally left off the “ES” … it was full OpenGL support … on the desktop, at that! O … M … G … L … !!! I’m stuck on a 100 Kbps Internet link for the moment, so it took a few hours to get the new distro downloaded, but now I’m ready to jump into 3D hyperspace!!!

This is enough of an advance for me to resume development of my long-planned STEM educational game, Pi-finity! Not being able to run it integrated with the desktop was highly unsatisfactory, but now that hurdle is mostly crossed and there are lots of other parts beyond the 3D graphics that need to be completed anyway, the most important being the P2P data sharing that obviates central servers being needed to maintain coordinated state across systems on the network.

I have Spring break coming up in a month and the Summer when school will be out, although I will be running computing Summer camps, Jams, and possibly Jamborees across the U.S., so I will be plenty busy, as usual. If I’ve made enough progress by then though, I’ll be able to publish a draft API and enough code for the basic functionality to run and then perhaps contributions by others can help accelerate development of the full system.

Thank you to the whole raft of people who made this possible, as well as all of the other upgrades that I’ll be checking out over the coming weeks. The future’s now so bright, we’ve _all_ gotta wear shades … 3D shutter-equipped shades, at that! :D

Yes, perfect. I have one comment… sound over HDMI does not work with the experimental opengl driver and I need that because sound has more quality like that (I can “feel” it in my ears) – I have a HDMI to VGA with 3.5 audio adaptor and my config.txt is:

I did an upgrade on a running Jessie and activated GLX in raspi-config. At first I was getting the flipping screen with the color square, after changing the PSU it was ok. It will run e17 great but I have an overscan problem which will not be affected by changes of overscan setup in config.txt. The overscan problem appears even after booting in text mode.
All in All it looks very promissing!

I’ve got a similar problem with a Pi2. On a fresh install, it boots fine and the driver works nicely – I watched the gears spin at 60 fps and played neverball. Great fun!

I then thought I’d update an existing Jessie SD card for the same pi, which worked fine right up until I enabled the hardware acceleration in raspi-config. When I rebooted, I just got the rainbow splash screen and nothing else. Multiple reboots did the same thing.

editing config.txt and commenting out this line, thus :
#dtoverlay=vc4-kms-v3d

allowed the pi to boot off the card once more. (I then went back to raspi-config and properly disabled the hardware acceleration). All is ok once more, though without hardware acceleration on that card.

So, on a fresh image, the new driver works fine. On an existing image that I updated, running on the same Pi2, it freezes on the splash screen.

I turned on camera, SPI and I2c support in raspi-config and overclocked to 1000MHz. Memory split unchanged from latest Raspbian image. Maybe I forgot one of these settings when the driver was running without problems. At the moment the Display is connected to the Pi2 but not to a power supply.
I added the power supply only when the Pi failed to boot.

Seems to work nicely on my pi2 with just one exception. After enabling the openGL driver and rebooting I seem to get 1 (or maybe 2) columns of magenta pixels at the very left side of my screen – this occurs both in the console and in the X Window System. Disable the openGL driver and reboot and the purple columns disappear again.

Is the new driver Eric Anholt’s open source driver? I wonder if it will be used for everything even when there’s no OpenGL, including the high res framebuffer. A few days ago I tried a custom build (http://sukzessiv.net/~gohai/vc4-buildbot/build/), but now the site has no builds anymore and says in a few words something that could be interpreted as if the current Raspbian (if the new driver is enabled) works completely without the closed source driver.

With just a little effort, I was able to get OpenMW running on the Raspberry Pi last night using the experimental driver. I only got maybe 10-15 FPS, but considering the developmental status of everything, it was still impressive and shows a lot of promise.

Blackscreen troublehooting: Narrowing this down to an HDMI display config somewhere. Two different Pi 2’s – same PSU, SD card etc. – only difference is the display. One works (Panasonic TV), the other gets black-screen after rainbow (cheap off-brand TV). Again, no difference in the setup except the display. Tried hdmi_boost=4, hdmi_drive=2 ; no change.

Swapped the Pi’s so the one that didn’t work is on the Panasonic, and vice versa. Pi that did not work on the small TV, now works on the Panasonic. Pi that worked before, show’s black screen when connected to the small off-brand TV.

My tests showed the same conclusion, the new driver does output an unusual HDMI format which is incompatible with some displays. Upgrading from previous Raspbian or starting with a fresh install does not matter.

When I enabled the new OpenGL system I got a problem where the raspberry pi would stretch the screen (or maybe the monitor) and the monitor would give an ‘out of range’ error. Is this a bug? How do I fix this?

Same problem with Panasonic TV. Enable/Disable overscan makes no difference and I can *just about* see enough of the screen left side and top to select (guess) the place to click. Disabling OpenGL brings things back to normal.

with the new native driver the pi can actually deliver 465fps on glxgears or 2335 frames in 5 seconds. Not a speed demon but still quite respectable for this little beast. To try for yourself you have to set an environment variable prior to running glxgears to disable vsync
export vblank_mode=0
glxgears

Great news. A major advantage of the Raspberry Pi over other small board computers is its software support. With the new OpenGL, I was able to watch Avogadro gracefully turn around oxytocin, a nine-amino acid polypeptide.

One thing. The new Raspbian did not have the ignore_LCD line in /boot/config.txt. I had to add ignore_LCD=1 to get it to display out the HDMI connector for class demos. (It had defaulted to my RasPi display.)

When will native GPIO screen support arrive? I have a screen and installing the drivers-from wheezy era-cause X to be modified to something that causes it to always crash. Also, the screen powers but just displays pure white. I can include link if needed.

excuse my slow thinking. I believe that OSS is a good thing in itself, but what other advantages does the new driver bring to the users? I saw Quake Arena running with the closed source OpenGL drivers – so what is missing? ;-)

Or is it that the closed source driver does only support OpenGL ES vs. full OpenGL in the OSS driver? If this is the main difference then it should get more emphasis.

After I rebooted with OpenGL the Volume Control in the panel disappeared, and when I try to add it back I get empty space instead. glxgears and Neverball works, but when I start Neverball sound doesn’t work and I get “Failure to open audio device (ALSA: Couldn’t open audio device: Filen eller katalogen finns inte)” (I use Swedish language). I normally use analog sound. Also, the lower part of the screen can’t be used — it’s the same gray as the background. I have a 4:3 screen, I think.

Yes! I had spent a couple of days recompiling the kernel, then just burned the last raspbian release without success. but the key was the video setting in /boot/cmdline.txt
pi@raspberrypi:/boot $ cat cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait video=1360×768

Just a follow up to my previous post, on my kernel parameter video=wxH the H seems to work only on H=768. I got the working combination (for my tv) by trying out values on output of /opt/vc/bin/tvservice (dump edid data, then parse, then try out the values). a cat of /proc/cmdline seems to help, there is a entry for bcm2708_fb.fbheight that is probably correct for the display device.

I believe that I have been following your instructions correctly about keeping my Raspbian software up-to-date, including those here about updating to Jessie. My system is still working fine! Dumb question: How do I know if I am now running Jessie rather than an earlier version of Raspbian? How do I know what version is running in my Raspberry Pi

I took your advice and did everything you suggested. What I had missed doing was the firmware upgrade – I must have missed where in the instructions that was mentioned. I now do have 4.1.17-v7+ as you said you have. However, when I did cat > /etc/os-release it still says: … Version =”7 (wheezy)”. Also, PRETTY_NAME = “Raspbian GNU/Linux 7 (wheezy)”. Still no mention of Jessie. So how can I tell I’m running Jessie?

After a completely new NOOBs and uploading the latest of the distro plus all that is required. I seem to be the only one with this interesting problem:
A totally black screen unless the mouse is moved. As soon as the mouse stops, the screen is black again. Regardless of anything else.
Any ideas what I was doing wrong?

So I upgraded my Rasbian installation and once again my desktop got screwed up. People, I really like the regular updates Raspbian receives but there’s a big no-go in my opinion which is messing around in one’s home directory. Believe me, I’ve already configured the desktop the way I like. So to me the resetting to your defaults seems like forcing your desktop design on me. I know – my configuration is stored in the “oldconffiles” folder but why is it necessary to write in my home folder, guys?

Today I took a few hours to test the experimental Open GL driver.
1) As already reported, blender finally works, but the right click used to select objects doesn’t. Surprisingly, right click with disabled experimental driver works though, but then 3d part of the scene is not rendered anyway (only the 2d HUD over the 3d scene).
2) supertux works great with 60 FPS using hardware opengl. However, supertux already worked before with 60 FPS using software renderer, but without GL effects. OTOH, running software opengl with effects had 1.5 FPS beforehand.
3) supertuxkart hard freezes on startup splash when using hardware opengl. Software emulation works, but is unplayable (<1 FPS).
4) extremetuxracer runs fine on hardware opengl for the first few seconds in 3d scene, but then runs with <1 FPS. I guess painting the belly track texture is giving RPi some trouble.

My turn to thank you for that driver and to share trouble I had.
I tried my RPI2 with OpenGL activated on 2 different TV:
* one didn’t support resolution. When OpenGL was activated, according to TV resolution changed from 1080p to something like 1150*??? (I don’t remember).
* other one, OK for the resolution but Desktop was displayed only if I moved the mouse. If I didn’t, as PaddyB said “i had display problems with the screen flipping between a rainbow pattern and normal”
So, like PaddyB, I changed my PSU (actually, it’s a smartphone charger) to a more powerful and it’s ok.
Thanks a lot

I’ve gotten past this I think. But now I’m onto another issue where the EDID information from my monitor isn’t being interpretted/presented correctly. I’m looking for a way to force 1080p at this point. Or if anyone else has any suggestions, that’d be helpful as well. All I know is that my monitor works when I’m not using the new GL driver, and with the GL driver I get a black screen when I start and the following error:

Hi, I am a complete new starter with the Pi. I have the Pi3 and bought the Raspberry Pi 7″ Screen and stand. Followed all install instructions and all fine except image on screen is upside down. Contacted the PiHut and their response is … I do not know what they mean can someone help be more specific… i.e. where do I type this command?, what editor?. I have tried typing this in the Terminal Screen after the $ but no joy…. apologies if this is really basic !!

“An update has been pushed to Raspbian to flip the screen ( rotate it by 180 degrees ) for a better desktop viewing angle. This makes it upside-down in our stand, so you’ll need to change a setting to flip it back.

To do this, open /boot/config.txt in your favourite editor and add the line:
lcd_rotate=2
This will rotate both the LCD and the touch coordinates back to the right rotation for our display stand.

Don’t use the documented display_rotate, it performs a performance expensive rotation of the screen and does not rotate the touch input.”

initially I was using the official 7″ touchscreen display and after scrolling the posts I realized there may be some problems with it.

However, I restarted the process (installing fresh jessie and updating it), while using a regular 24″ computer monitor (with HDMI). After I enabled the OpenGL driver and rebooted, I get a blank screen instead (Rpi3 is plugged to an external monitor through HDMI, the 7″ touchscreen is un-plugged from RPi3).

Hello.
I run Raspbian Lite on Pi 3. I did dist-upgrade just yesterday. After upgrade I see unwanted disc activity – LED is blinking every second.
Can somebody tell me, what is going on? How can I prevent this disc IO?

I observed the following behaviour:
As soon as I activate the Open GL feature, the screen size on my Samsung ue55C6700 TV set gets misallocated.
About 16 -30 pixels to each side are beyond the visible screen.
I tried to allocate the screen size manually to no avail. I seems that the OGL feature completely surpasses the raspi-config and uses its own hdmi driver.
As soon as I switch off the OGL, the screen size responds again according to the raspi-config.
On my LG monitor m2380 there is no such issue.
Did anyone else experience such issues?