Language Selection

English French German Italian Portuguese Spanish

Graphics: X.Org Server and Red Hat Hiring

Filed under
Graphics/Benchmarks
  • xserver release process and gitlab

    I was asked off-list what tasks are involved in releasing a new X server, since eventually people are probably going to want one.

    And that's a good question! The unfortunate answer is that the process has been informal and has varied over time. We have often used tracking bugs in bugzilla to define the set of remaining issues to address within a release, but we're not using bugzilla anymore. So I think it's probably a good idea to start with the processes available to us in gitlab. From what I can tell, "milestones" are the best fit for this.

  • The Process For Eventually Releasing X.Org Server 1.21

    While formally the X.Org Server aimed to put out a new feature update every six months, in recent years they have been well off that trajectory with not much feature activity going on especially now that GLAMOR / XWayland / xf86-video-modesetting have stabilized and many Linux distributions eyeing Wayland by default. But there is now at least some little bit of interest in what's going into X.Org Server 1.21.

    It's already been one year since the release of X.Org Server 1.20 and it doesn't appear the 1.21 update is imminent. Adam Jackson of Red Hat who has served as the release manager the past several cycles says he was asked off-list by an unnamed person about what goes into releasing a new version of the xorg-server.

  • Dave Airlie (blogspot): Senior Job in Red Hat graphics team
  • Red Hat Is Looking To Hire Another Experienced Open-Source Graphics Driver Developer

    Red Hat is hiring for their open-source graphics driver team.

    Red Hat developers already oversee the Nouveau DRM kernel driver, manage the mainline Linux kernel's DRM subsystem, work on the VirGL stack, working on plumbing the SPIR-V / NIR compute support for Nouveau, and the other efforts over the year by David Airlie and others... There's a lot of upstream open-source work they do for graphics and related areas like libinput.

More in Tux Machines

today's howtos

KDE Frameworks 5.61, Applications 19.08 in FreeBSD

Recent releases were KDE Frameworks 5.61 and KDE Applications 19.08. These have both landed in the official FreeBSD ports tree, after Tobias did most of the work and I pushed the big red button. Your FreeBSD machine will need to be following current ports – not the quarterly release branches, since we don’t backport to those. All the modern bits have arrived, maintaining the KDE-FreeBSD team’s commitment to up-to-date software for the FreeBSD desktop. The one thing we’re currently lagging on is Qt 5.13. There’s a FreeBSD problem report tracking that update. Read more

Dev branch moving towards Qt 6

As you know, Qt 5.14 will be branched pretty soon. After that I would expect that most new development work would start to be aimed towards Qt 6. As it looks right now, 5.15 will be a smaller release where we polish what we have in 5.14, and prepare some things for Qt 6. To reflect that and help us all understand that the development focus is now towards Qt 6, I would like to propose that dev becomes the Qt 6 branch after we branched away 5.14 (and we merge wip/qt6 back into dev). We can then either create a 5.15 branch at the same time, or slightly later, once 5.14 has stabilised a bit more (e.g. after the beta or RC). Read more Also: Qt's Development Branch To Begin Forming Qt 6

Today in Techrights