你好 北京!
Hello Beijing and lovely people of openSUSE, I will be reaching there tomorrow, will be at Green Tree Inn close to the summit venue, packing some “sightseeing” before the event, if you are also there early drop me a line . There is a short talk about openSUSE Education scheduled on 19th. Check out the summit website to find out what other interesting stuff is on offer.
See you soon…
As of October 11th, a bunch of new rpm for FGLRX has been released for openSUSE 11.4 to 13.1 including Tumbleweed.
a special patch has been added for supporting up to kernel 3.17
Please refer to the wiki page SDB:AMD_fgrlx_legacy
This release concern only owners of radeon HD5xxx or above.
For older gpu, the fglrx-legacy is still 13.1, and thus didn’t work with openSUSE 12.3 or above.
SDB:AMD_fgrlx_legacy
Beware of that, and prefer the free open-source radeon driver which came out of the box from your openSUSE distribution.
For 12.3 and especially 13.1 the free radeon often offer a better experience than the old fglrx-legacy, especially for HD2xxx-HD4xxx range.
Dear fellow, unfortunately an still open bug at AMD is not yet resolved to make FGLRX working under newer xorg version.
There’s also a re-organization of how xorg files will be placed in the file system. Once both of them will be fixed Sebastian will produce a newer script.
If those appear soon we perhaps will see rpm fglrx for 13.2.
New Features:
The following section provides a summary of new features in this driver version.
AMD Radeon™ R9 285
Ubuntu 14.04 support
RHEL 7.0 support
Install improvements
Package and distribution generation options; recommend options set by default
Help user install generated distribution package once created
Pop-up messages to help guide users through the install process
Identifying and installation of pre-requisites
Resolved Issues:
This section provides information on resolved known issues in this release of the AMD Catalyst Linux Software Suite.
Witcher 2 random lock-up seen when launching the application Screen corruption when connecting an external monitor to some PowerXpress AMD GPU + Intel CPU platforms Intermittent X crash when the user does a rotation with Tear Free Desktop enabled Failure on exit of OpenGL programs Error message being displayed when a user does run clinfo in console mode Blank screen when hot plugging an HDMI monitor from a MST hub System hang after resume from S3/S4 in High Performance mode on PowerXpress AMD GPU + Intel CPU platforms Corruption or artifacting on the bottom right corner of the screen before booting into login UI during restart Occasional segmentation fault when running ETQW xscreensavers test failing with multi-GPU Crossfire™ configurations Motion Builder severe flickering while toggling full screen Intermittent crashing and corruption observed while running X-Plane Some piglit and Khronos OpenGL conformance test failures Displays occasionally going black when startx is run on Ubuntu 14.04 after switching to integrated GPU on PowerXpress AMD GPU + Intel Haswell CPU system platforms A connected external display getting disabled when unplugging AC power from laptop platforms An auto log out when double clicking the picture under desktop server times on PowerXpress AMD GPU + Intel CPU platforms
Known Issues:
The following section provides a summary of open issues that may be experienced with the AMD Catalyst Linux Software Suite.
[404829]: Horizontal flashing lines on second screen in a clone mode with V-Sync on using AMD Mobility Graphics with Switchable Intel Graphics [404508]: Display takes a long time to redraw the screen after an S4 cycle
This Catalyst fglrx version support openSUSE version from 11.4 to 13.1 plus Tumbleweed (thus covering kernel from 3.11 to 3.17 series).
A special thanks to Sebastian Siebert for his effort on making this driver working under openSUSE and latest kernel.
Hi,
My motivation for writing this blog post is to have one simple place where I can point everybody using += in a loop. I will describe here why it can kill the performance of any application or library and will also show some measurement to demonstrate it. (more…)
To share a bit more about this long trip but worth to made it.
You can now enjoy the video clip made during this event.
Was a real pleasure to meet so numerous openSUSE users.
If running a booth is, for sure, an investment of time, energy and money (even if TSP contribute to help you), We often forget to say
how much it’s important for our community and project.
Booths makes openSUSE alive in all open source events! and it’s a great experience to live, for any of us.
I strongly believe that openSUSE has be to visible on events like KDE Akademy, Scale, Fosdem, Guadec.
It’s not a question of "Bang for the buck", than a simple obviousness:
The obviousness is: if openSUSE has no booth there, you just see Ubuntu and Redhat, and let’s add Debian, Mageia etc for Fosdem or Scale.
You all know how much I like our Geeko community. And when Akademy staff proposed us to run a booth, I said yes, great I will be there!
After comparing ways to go to Brno, the Geeko’s car was the less expensive, and allow me to pick the demo touch screen at SUSE Headquarter.
So I took a full week off and drive 2000 kilometers to make it happens.
Have you ever dreamed making your own unique font set. You get on it and seek for decent cheap or open source alternatives for making Truetype fonts and probably you find at least Fontforge. You are very happy and make you mind I’ll do my fonts with Fontforge. After a while you realize Fontforge is a Swiss army knife for making fonts in open source but you just wanted to create TTF, EOT or SVG font set. Weep no more you can use Birdfont. (more…)
As it has taken an extra ordinary amount of time for LSB to move forward a predicament has developed for many distributions, including openSUSE. Many of the requirements for LSB 4.1 can no longer be met and thus while the lsb package still builds it is not installable, see . The technically correct solution would be to drop the lsb package from the distribution, Factory now and thus 13.2 when it is released) as we can no longer be LSB compliant. However, the negative side effect is that some applications we do not and cannot package will no longer install, probably most notably google-chrome. Thus, having no lsb package, or no package that provides “lsb”, is a problem and has negative effects on many users. Therefore, the only way forward is to have an “lsb” package which provides LSB on a best effort basis.
Since LSB 4.1 and previous releases is a monolithic requirement, i.e. if you depend on lsb you depend/get everything that is in the standard, whether you want it or not, it is very likely that many applications depend on lsb while needing only a subset of the features. Thus, while we do not know all of those applications and cannot provide a list of “this will work and that will not“, there is a good chance that many external packages depending on lsb will not only install, but the payload they deliver will work with an lsb best effort approach. For those applications that are broken there is pretty much nothing we can do, sorry.
At a meeting last week at LinuxCon NA the goal was set to have LSB 5.0 released by the end of October. LSB 5.0 is incompatible with LSB 4.1 and prior releases. Thus, even if we provide an lsb 5.0 compliant package in short order after LSB 5.0 is released we still have the same risk as we do with the best effort approach. Basically some application packages that depend on “lsb” will deliver a payload that is broken. Exactly the opposite of what the LSB is trying to achieve, but hey one cannot hang on to Qt3 forever. Therefore, our “lsb best effort” approach to cover the gap does not create any additional pain.
Moving forward the LSB working group decided that the current approach, while providing value, has significant drawbacks. Predominantly there are not enough fingers on the keyboard to continue releases of such extensive “accepted standard” documentation. This is what we presently experience with the non installable lsb package. A for the LSB is being worked out. As this next/new LSB develops we will have to see how application providers deal with this. Without a formal LSB specification in the future, this problem will recur in a few years if application packages depend on a package named “lsb” which at some point may need to seize to exist. We will see how this plays out as the world we create keeps evolving.
Konqi Randa Mascot
2 Weeks ago myself and Françoise had joined the [http://www.randa-meetings.ch/ Randa Meeting] in Switzerland.
This event is a full hack-week where between around fifty people, that help to change the world, met together and hack around [http://www.kde.org KDE Community] related stuff. More on
KDE sprint page
I’ve heard about Randa from years, and had seen numerous reports about how Randa hack-week has allowed lots of changes : Plasma, Software collection, etc…
This year, we decided not only to financially sponsor the event, but also be part of as simple helper, with the status of newcomers in the KDE community contributors. Just to check how it goes.
Mario Fux (the organizer) didn’t fake his involvement to make this week a success, in a full open source spirit.
We’re reporting below a number of blog post that have been made during the hackweek.
And as the icing on the cake, you could just watch the video realized during the week.
I’ve been talking about how code construction is necessary to your coding project. With Javascript obfuscation or making code shine is more important than ever. There will be many many eyes looking at your code and see if it’s worth of nothing. After getting friend with js-beautify there ain’t no excuse to keep you ugly looking code laying around. (more…)
Back on line after several weeks in late, I’ve tried from my best to resolve the case of Factory rolling releases.
After some hacks on the latest Sebastian Siebert beta version (Made in June), I’ve been able to build now BETA fglrx rpm for several openSUSE version.
one day AMD will release or not a stable version. (On my side I prefer to see more efforts made on the free radeon driver.)
This release concern only owners of radeon HD5xxx or above. All owner of HD2xx and HD4xx are really encouraged to use the free radeon driver (which received a lot of improvement in 3.11+ kernels)
This is experimental & BETA software, it could fix issues you encountered (FGLRX not working for openSUSE 13.1),
I would like to have some news about Sebastian Siebert, he’s a essential key for future updates.
This time I was able (even with several weeks in late) to adjust the script to create a build for openSUSE Factory.
But one day something will broke in kernel or somewhere else, and we all need to find a way to fix it.
So if you’re in touch with Sebastian, could you drop me a comment or a private mail?
I would like to continue the good support we created 3.5 years ago, or at least knowning if I’m orphan 🙁
To make things clear about the status of the drivers, it will not be published under the normal stable repository http://geeko.ioda.net/mirror/amd-fglrx.
I’ve created some times ago a beta repository located at http://geeko.ioda.net/mirror/amd-fglrx-beta.
The FGLRX 14.20 beta1 rpm are released for openSUSE version 12.3, 13.1 (+Tumbleweed), Factory
Signer of package my generic builder gpg key at Ioda-Net. (gpg key id 65BE584C)
For those interested by contributing or patches done to last Sebastian version, the raw-src on the server contain all the material used
http://geeko.ioda.net/mirror/amd-fglrx-beta/raw-src.
Admitting you’ve the normal repository named FGLRX, (use zypper lr -d to find the number or name you give it). You have to start by disabling it
so you could fallback to it quickly when new stable version will be published. Open a root console or add sudo at your convenience and issue the following command:
zypper mr -dR FGLRX
To add another repository in the same console as root issue the following command which will install normally the right repository for your distribution
zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/mirror/amd-fglrx-beta/openSUSE_`lsb-release -r | awk '{print $2}'` FGLRX-BETA
If you are using Tumbleweed use this one
zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/mirror/amd-fglrx-beta/openSUSE_Tumbleweed FGLRX-BETA
Now the update/upgrade process
zypper dup -r FGLRX-BETA
Let the system upgrade the package, and try to enjoy the new beta.
Adrian Schröter (12)
Agustin Chavarria (6)
Alessandro de Oliveira Faria (13)
Alex Barrios (12)
Alexander Naumov (10)
Alexander Orlovskyy (3)
Alin M Elena (5)
Andrea Florio (27)
Andreas Jaeger (70)
Andreas Stieger (12)
Andrew Wafaa (31)
Arvin Schnell (9)
Atri Bhattacharya (3)
Bernhard Wiedemann (31)
Bonnie Kurniawan (1)
Bruno Friedmann (98)
Calumma Brevicorne (29)
Carl Fletcher (1)
Christopher Hobbs (17)
Ciaran Farrell (3)
Stephan Kulow (17)
craig gardner (2)
Stephan Barth (2)
Thomas Schmidt (2)
Dinar Valeev (1)
Dirk Mueller (2)
Dmitry Serpokryl (7)
Efstathios Iosifidis (21)
Fabio Mucciante (5)
Federico Lucifredi (9)
Greg Freemyer (1)
Holger Sickenberg (2)
Hubert Mantel (1)
Ilya Chernykh (5)
Ismail Donmez (1)
J. Daniel Schmidt (2)
James Tremblay (7)
Jan Blunck (4)
Jan Loeser (3)
Jan Madsen (1)
Jan-Christoph Bornschlegel (3)
Jan-Simon Möller (20)
Javier Llorente (12)
Jigish Gohil (85)
Jiri Srain (1)
Jiří Suchomel (3)
Johan Kotze (5)
José Oramas M. (6)
Josef Reidinger (16)
Juergen Weigert (1)
Julio Vannini (9)
Dinar Valeev (5)
Kevin "Yeaux" Dupuy (11)
Klaas Freitag (55)
Lars Vogdt (11)
Ludwig Nussel (13)
M. Edwin Zakaria (4)
Marcus Hüwe (39)
Marcus Meissner (2)
Marcus Moeller (3)
Marcus Schaefer (4)
Martin Lasarsch (8)
Martin Mohring (11)
Masim "Vavai" Sugianto (20)
Michael Andres (1)
Michael Löffler (7)
Michal Marek (7)
Michal Vyskocil (12)
Miguel Angel Barajas Hernandez (2)
P Linnell (2)
Nelson Marques (55)
Nenad Latinović (1)
Nikanth Karthikesan (2)
Przemyslaw Bojczuk (1)
Peter Pöml (4)
Petr Gajdos (2)
Petr Mladek (60)
Petr Uzel (5)
Ray Wang (1)
Raymond Wooninck (1)
Ricardo Chung (7)
Ricardo Varas Santana (7)
Richard Bos (11)
Robert Schweikert (16)
Rossana Motta (1)
Rupert Horstkötter (10)
Sascha Manns (66)
saydul akram (3)
Sebastian Siebert (6)
Shawn Dunn (2)
Stanislav Visnovsky (7)
Stefan Haas (1)
Stefan Hundhammer (5)
Stefan Schubert (7)
Steffen Winterfeldt (8)
Suresh Jayaraman (3)
Susanne Oberhauser (3)
Thomas Göttlicher (6)
Thomas Schraitle (26)
Togan Muftuoglu (3)
Tuukka Pasanen (36)
Will Stephenson (22)
YaST Team (90)