Project

General

Profile

Actions

Action Item #128

closed

Add support for hardware accelerated X.org

Added by Hammel almost 12 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Immediate
Assignee:
Category:
04 - Root File System
Target version:
Start date:
07 Nov 2012
Due date:
% Done:

100%

Estimated time:
Severity:
02 - High

Description

Not sure if this support already exists. If not, fallback to software enabled or perhaps frame buffer driver.

Actions #1

Updated by Hammel almost 12 years ago

  • Priority changed from Immediate to Normal
  • % Done changed from 0 to 50
  • Severity changed from High to Medium

There is no hardware accelerated X for Raspberry Pi at this time.

I updated the xorg.conf file and switched the xinitrc to blackbox. X now starts correctly using the fbdev driver.

I'll leave this one open until a hardware accelerated driver arrives.

Actions #2

Updated by Hammel over 11 years ago

  • Severity changed from Medium to 03 - Medium
Actions #3

Updated by Hammel over 11 years ago

  • Target version changed from 0.3.0 to 1.0 - Atreides
Actions #4

Updated by Hammel almost 11 years ago

  • Target version changed from 1.0 - Atreides to 2.0 - Harkonnen
Actions #5

Updated by Hammel almost 11 years ago

There appears to be a hardware accelerated driver now that is a drop in replacement for the xf86-video-fbdev driver I'm currently using.

See https://github.com/ssvb/xf86-video-fbturbo

Actions #6

Updated by Hammel over 10 years ago

  • Priority changed from Normal to Urgent
  • Target version changed from 2.0 - Harkonnen to 0.8.0
Actions #7

Updated by Hammel over 10 years ago

  • Status changed from New to In Progress
  • % Done changed from 50 to 70

Built a buildroot package for it and did a test build. Builds okay with mods for buildroot xorg config (xf86driproto).

Tested on hardware and it comes up fine. Verified it was working in Xorg.log.0. Not sure if 3D is working but 2D acceleration should be there. Don't see great difference in starting surf, however. It still runs slow.

Need to verify complete and current buildroot build works with new package. Then I can check in updates for the new driver, including updating the xorg.conf to use it.

Actions #8

Updated by Hammel over 10 years ago

Left the driver running overnight and found that the display was partially unrefreshed. Hitting a keystroke (shift key) refreshed it.

Actions #9

Updated by Hammel over 10 years ago

Pushed updates upstream.

Actions #10

Updated by Hammel over 10 years ago

  • Target version changed from 0.8.0 to 1.0 - Atreides

Pushing this to later release to give driver time to become more stable.

Actions #11

Updated by Hammel over 10 years ago

  • Target version changed from 1.0 - Atreides to 0.9.0

Moving to 0.9 to test updates to the driver with newer kernel/gcc/glibc and rootfs.

Actions #12

Updated by Hammel over 10 years ago

  • Priority changed from Urgent to Immediate
  • Severity changed from 03 - Medium to 02 - High
Actions #13

Updated by Hammel over 10 years ago

Building for 3.10.y - there are currently no updates to the project so this is the same code that was less stable than the standard fbdev with the 3.2.27 kernel.

Also, there is an alternative X.org driver with additional information on using it at eLinux.org.

Actions #14

Updated by Hammel over 10 years ago

Doh - the driver was already enabled and built. It just wasn't used in the xorg.conf. I've switched to it and will let it sit for a while to see what happens.

Actions #15

Updated by Hammel over 10 years ago

After one screen blanking, a keypress brought it back without problem. I'm going to reboot and test if the keyboard is available on first boot (instead of requiring an Xorg restart) and then let it sit overnight and see if its still okay in the morning.

Actions #16

Updated by Hammel over 10 years ago

Xorg still requires a restart on first boot with fbturbo and 3.10.31+.

Leaving overnight to see if driver is okay after long time unattended.

Actions #17

Updated by Hammel over 10 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 70 to 100

Seems to still be working just fine. I've made it the default for now.

Closing issue. If the driver causes problems I can reopen it.

Actions

Also available in: Atom PDF