[Openchrome-users] Trying to get Openchrome (update) working on HP2133 and openSUSE Tumbleweed

[Kevin Brace]

Hi Keith,

> Date: Sat, 27 May 2017 10:45:51 -0400
> From: Keith Mitchell <keith at smoti.org>
> To: openchrome-users at lists.freedesktop.org
> Subject: [Openchrome-users] Trying to get Openchrome (update) working
> 	on HP2133 and openSUSE Tumbleweed
> 
> First up, a big thank you to all openchrome developers for your efforts,
> I got 4 solid years of productive use out of my trusty HP Mini Note 2133
> thanks to your work :-)
> 
> I've been inspired by Kevin's recent efforts kicking life back into this
> project to attempt getting my HP2133 updated as a fall-back laptop.
> 

Thank you for the words of encouragement.
I am also using HP 2133 for active development and primary testing purposes.
I use it with a 120 GB SSD I purchased before the Flash memory prices went up late last year due to a shortage (capacity shortage due to planar NAND to 3D NAND Flash fab conversion).
It is nice that I no longer have to worry about hard drive head crash during use.


> I'm trying to do this with openSUSE Tumbleweed (build 20170521 for i586,
> package xf86-video-openchrome version 0.6.0-1.1), but am running into
> the following errors on X startup:
> 
> [ 39555.119] (EE) Failed to load module "via" (module does not exist, 0)
> [ 39555.138] (EE) open /dev/dri/card0: No such file or directory
> [ 39555.295] (EE) CHROME(0): [drm] Failed to open DRM device for
> pci:0000:01:00.0: No such file or directory
> [ 39555.299] (EE) CHROME(0): Unable to map the frame buffer.
> 

About a year ago, I filed a bug report with Linux kernel develops about vesafb snatching frame buffer before X Server starts.
It affected Linux kernel 4.5.
I got no response.
Blacklisting vesafb was the workaround, so you will like to try it.


> I suspect this is probably an installation error rather than a bug,
> seems like VIA DRM is missing/broken. I'm confused however about which
> DRM I should be running from where, and how to build/install, or even if
> needed.
> 

I do not think the old OpenChrome DRM (DRI1) supports P4M900 / VN896 / CN896 chipsets.
I think the development ended around 2007 for the most part.
P4M900 family was released around 2007.
The newer DRM supporting DRI2 and KMS (Kernel Mode Setting) has been in development since 2011, but it is still nowhere near completion.
It has a fatal memory management issue I have yet to figure out how to fix it.
For the past few weeks, I have been working on improving the existing code's display resources probing and initialization, and trying to fix hardware cursor related problems.
Most of the improved probing and initialization code has been committed, but I have not found solutions to the hardware cursor problems.
Because of these activities, the newer OpenChrome DRM development has stalled for now, but when the flat panel code is more stable, I will resume the development.


> The 4.11.1 kernel that comes with this Tumbleweed build is missing:
> 
>   /lib/modules/4.11.0-1-pae/kernel/drivers/gpu/drm/via/via.ko
> 
> (apparently removed since 4.9.x for security reasons [*] )-:, but I get
> exactly the same problem with an earlier 4.8.11 kernel which does
> include this.
> 

I objected to this, but I just got ignored (the discussion happened around August 2016).


> I've also tried compiling and installing the openchrome driver from the
> xf86-video-openchrome-0.6.0.tar.gz source tarball, again same result.
> 
> Am running with an empty xorg.conf, as that is what worked great before
> I upgraded this laptop (from SuSE 11.4, kernel 2.6.37.6, openchrome
> 0.2.904).
> 
> Have dumped various files about the state of my system, including
> Xorg.0.log, at http://www.smoti.org/openchrome/ FWIW.
> 
> I really need 2D acceleration to work, _don't_ need 3D or video
> playback, but would love to get dual-head working.
> 

I will likely work on 3D after I get the new DRM mainlined.
This will take a while.
Dual head works right now since I test it all the time.
The only limitation is that you cannot display more than 2044 total dots in the horizontal direction due to hardware limitations.
If you want more than 2044 dots, you need to use 16 bit color mode.
With 16 bit color model you can handle as much as 4092 dots if I am correct.
Vertical direction has far less limitations.


> Would appreciate any pointers on what I may (or SUSE) be getting wrong.
> 

Try blacklisting vesafb.


> Thanks,
> 
> Keith
> 
> 
> [*] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1680276
>

Regards,

Kevin Brace
The OpenChrome Project maintainer / developer