Just for your information, I am replying to this bug report from HP 2133 mini-note.
It appears that some models sold in certain countries got 1024 x 600 resolution flat panel, US (United States of America) model got 1280 x 768 resolution flat panel.
Furthermore, the 1280 x 768 resolution flat panel I have is I2C capable (it is made by CMO; Chi Mei Optoelectronics), but looking at the Xorg.0.log you supplied for OpenChrome DDX Version 0.4 shows that it is not connected to I2C bus.
I would imagine that I will need to use PCI subvendor ID and subdevice ID to handle HP 2133 as a special case (i.e., basically a "quirk" table type of an approach).
    By the way, you do not need to put multiple files into an archive file.
Just attach two log files (i.e., Xorg.0.log for Version 0.4 and 0.6) to the bug report.
I prefer it this way so that I can read the attachments from an Android tablet (actually, an Amazon tablet that uses a forked version of Android OS).

Can you attach an lspci output?

lspci -vvnn > ("File Name").txt

I do have an HP 2133 myself, but it is the version with the higher resolution and I2C bus capable flat panel.

Created attachment 142651 [details]
lspci -vvnn >

if it can help, HPmini 2133 with screen at 1024x600,
to solve this issue,

$ cat /etc/X11/xorg.conf
Section "Monitor"
    Identifier      "FP-1"
    Modeline        "1024x600_60.00" 49.00  1024 1072 1168 1312  600 603 613 624 -hsync +vsync
    Option          "UseEdidDpi" "False"
    Option          "PreferredMode" "1024x600_60.00"
EndSection

Section "Screen"
    Identifier      "Screen 0"
    Device          "VIA Technologies, Inc. CN896/VN896/P4M900 [Chrome 9 HC]"
    DefaultDepth    24
    SubSection "Display"
           Depth   24
           Modes   "1024x600" 
    EndSubSection
EndSection

(In reply to gabbo from comment #3)

I will go make a patch to specifically address this issue.
I hope to have it ready in a few days.


> Created attachment 142651 [details]
> lspci -vvnn >
> 
> if it can help, HPmini 2133 with screen at 1024x600,
> to solve this issue,
> 
> $ cat /etc/X11/xorg.conf
> Section "Monitor"
>     Identifier      "FP-1"
>     Modeline        "1024x600_60.00" 49.00  1024 1072 1168 1312  600 603 613
> 624 -hsync +vsync
>     Option          "UseEdidDpi" "False"
>     Option          "PreferredMode" "1024x600_60.00"
> EndSection
> 
> Section "Screen"
>     Identifier      "Screen 0"
>     Device          "VIA Technologies, Inc. CN896/VN896/P4M900 [Chrome 9 HC]"
>     DefaultDepth    24
>     SubSection "Display"
>            Depth   24
>            Modes   "1024x600" 
>     EndSubSection
> EndSection

In your November 25th blog entry you mention that you would still like to fix this bug but unfortunately the original poster has not responded so far. I have exactly the same issue and also the European style 1024x600 hardware. I would be glad to step in and help testing. The HP Mini 2133 runs Xorg 1.19 on dCore-Bionic which is Tinycore Linux with Ubuntu 18.04 packages.

So far I have tried to manually force 1024x600 resolution via xrandr with modelines obtained by cvt. However that changes things to the worse by stretching instead of compressing vertically, thereby hiding even more of the desktop. The same when using the xorg.conf as provided by user gabbo from comment 3. Forcing 1024x480 resolution makes the screen repeat the top portion in the lower part.

I shall attach the output of lspci -vvnn again.

Created attachment 142832 [details]
lspci -vvnn (again, for comparison)

Created attachment 142921 [details]
Xorg.o.log vers.0.6.180

something went wrong,
version 0.6.180 does not work

Fatal server error:
[    27.745] (EE) AddScreen/ScreenInit failed for driver 0

attachment Xorg.o.log openchrome vers.0.6.180

Created attachment 142922 [details]
Xorg.0.log vers.0.6.179

for comparison

Xorg.0.log openchrome vers.0.6.179

Myself and the person who helped me track down the VT screen bug tested Version 0.6.180 and 0.6.181, and they both worked.
We both used HP 2133 with a 1280 x 768 flat panel, although the OS tested with was different (Xubuntu 16.04.5 LTS with X.Org X Server 1.19.6 for myself, Debian based Knoppix 8 for the other person).


(In reply to gabbo from comment #7)
> Created attachment 142921 [details]
> Xorg.o.log vers.0.6.180
> 
> something went wrong,
> version 0.6.180 does not work
> 
> Fatal server error:
> [    27.745] (EE) AddScreen/ScreenInit failed for driver 0
> 
> attachment Xorg.o.log openchrome vers.0.6.180

I will need to take back the previous statement.
I did make a patch for 1024 x 600 FP without EDID, but when I use this, it then causes problems with my 1280 x 768 FP, particularly involving standby resume.
At this point, I am not sure when this bug can be fixed.
Looking at the Xorg.0.log posted by gabbo, it appears that gabbo's 1024 x 600 FP is from LG Display and supports EDID.
Although not with X Server 1.19, but I have observed unreliable I2C behavior with older X Servers (around 1.7 or 1.11).
I am not sure why the original poster was having this issue.


(In reply to sm8ps from comment #5)
> In your November 25th blog entry you mention that you would still like to
> fix this bug but unfortunately the original poster has not responded so far.
> I have exactly the same issue and also the European style 1024x600 hardware.
> I would be glad to step in and help testing. The HP Mini 2133 runs Xorg 1.19
> on dCore-Bionic which is Tinycore Linux with Ubuntu 18.04 packages.
> 
> So far I have tried to manually force 1024x600 resolution via xrandr with
> modelines obtained by cvt. However that changes things to the worse by
> stretching instead of compressing vertically, thereby hiding even more of
> the desktop. The same when using the xorg.conf as provided by user gabbo
> from comment 3. Forcing 1024x480 resolution makes the screen repeat the top
> portion in the lower part.
> 
> I shall attach the output of lspci -vvnn again.

Created attachment 142932 [details]
Xorg.0.log vers 0.6.181

I'm sorry,
I was in too much of a hurry to report,

after a few tests, here are some considerations:
to solve the probable problem of the wrong solution on my "hpmini-2133 1024x600fp", I created an xorg.conf using a modeline from the cvt, see comment 3,
now without which X fails, at least previously it started using an incorrect resolution, I don't understand why it doesn't use the EDID information correctly,

attached version 0.6.181 working with the above xorg.conf,

my best regards

Created attachment 143023 [details] [review]
HP 2133 Mini-Note 1024 x 600 flat panel model only patch 1

This patch is only for HP 2133 Mini-Note 1024 x 600 flat panel users only.
While it can be used with a 1280 x 768 flat panel model, that will cause screen resolution related odd behavior when resuming from standby.
Generally apply against OpenChrome DDX Version 0.6.181 or similar (i.e., 0.6.179).

Created attachment 143083 [details]
lspci -vvnn for latam hpmini with 1024x600 panel

Hello Kevin, my appologies for my slow response, but I'm back and ready to colaborate.

I'm sending the lspci output for my HP mini using archlinux 32 kernel 4.20

Any testing that you need please let me know.

Best regards

Go ahead and apply the temporary patch over DDX Version 0.6.181 for now.

$ patch -p 1 < ("Name of the patch")

Do so from /xf86-video-openchrome.


(In reply to xanum from comment #14)
> Hello Kevin, my appologies for my slow response, but I'm back and ready to
> colaborate.
> 
> I'm sending the lspci output for my HP mini using archlinux 32 kernel 4.20
> 
> Any testing that you need please let me know.
> 
> Best regards

Created attachment 143115 [details]
Xorg Log from patched openchrome 0.6.181

I have compiled the 0.6.181 driver with your patch in my 1024x600 hp mini and installed using 'make install'

After the reboot, the screen resolution is correctly set to 1024x600, no flicker or any other visible problem. Also the standby resume works OK. I'm attaching the Xorg log.

But I see the following problem with the bottom panel: 

I'm using LXDE with xdm for the login page, also I have a task bar of 50 pixels high with transparency over a standard LXDE wallpaper. After the login page, the taskbar is rendered correctly, but after a few seconds, the task bar flickers and the wallpaper seems out of sync in the 24 last pixel rows of the screen. Also if I log out and return to the login screen, is rendered in a 1024x576 screen and the last 24 pixel rows remain with the LXDE wallpaper. In the next attachements I show screenshots with the normal screen and the unusual one.

From reviewing the Xorg Log, I see that the VGA output is detected as connected and is set to a 1024x576 (exactly the 24 pixel rows that are the problem). I don't have any monitor connected to the VGA output. Could be this the problem?

Best regards

Created attachment 143117 [details]
Normal transparent task bar over a LXDE wallpaper

Created attachment 143119 [details]
Wrong task bar missing last 24 pixel rows and broken wallpaper

It appears that you are seeing false detection of a VGA connector.
This feature was added during the OpenChrome DDX Version 0.7 development cycle, but it is proving to be less than reliable with some models, particularly newer single chip Chrome IGP (i.e., CX700 / VX700, VX800, VX855, and VX900)
In practice, it affects several models other than the single chip Chrome IGP.
I have observed false detection with Neoware m100 
I was thinking of disabling the code, and only use I2C bus based detection for a VGA connector.
The only drawback to this is that it will not be able to support a VGA connector with its I2C being broken (it happens with some people) or a really, really old VGA monitor without I2C bus support (i.e., from late '80s to early '90s).
In the interest of making the device driver work for more users, I will take out the VGA connector detection code.


(In reply to xanum from comment #16)
> Created attachment 143115 [details]
> Xorg Log from patched openchrome 0.6.181
> 
> I have compiled the 0.6.181 driver with your patch in my 1024x600 hp mini
> and installed using 'make install'
> 
> After the reboot, the screen resolution is correctly set to 1024x600, no
> flicker or any other visible problem. Also the standby resume works OK. I'm
> attaching the Xorg log.
> 
> But I see the following problem with the bottom panel: 
> 
> I'm using LXDE with xdm for the login page, also I have a task bar of 50
> pixels high with transparency over a standard LXDE wallpaper. After the
> login page, the taskbar is rendered correctly, but after a few seconds, the
> task bar flickers and the wallpaper seems out of sync in the 24 last pixel
> rows of the screen. Also if I log out and return to the login screen, is
> rendered in a 1024x576 screen and the last 24 pixel rows remain with the
> LXDE wallpaper. In the next attachements I show screenshots with the normal
> screen and the unusual one.
> 
> From reviewing the Xorg Log, I see that the VGA output is detected as
> connected and is set to a 1024x576 (exactly the 24 pixel rows that are the
> problem). I don't have any monitor connected to the VGA output. Could be
> this the problem?
> 
> Best regards

Unfortunately, I am not getting anywhere here so I would be very thankful for some guidance and help! I cloned version 0.6.182 from Github and applied the patch to it. Then I compiled it on a machine with Ubuntu 16.04. 

Afterwards, I copied the files /usr/lib/i386-linux-gnu/libchromeXvMC*.so* and /usr/lib/xorg/modules/drivers/openchrome_drv.so in place on the HP Mini 2133 which runs dCore-Bionic, a variant of Tinycore Linux using Ubuntu Bionic packages. 

The files are the relevant ones from the Ubuntu package xserver-xorg-video-openchrome. The Xorg is version 1.19.6 and version 0.6.0 from the Ubuntu Bionic package works but obviously uses the wrong screen resolution.

The result after issuing startx is an utterly broken system that does not react to anything but the system request keys. I am no expert in any of this by far and therefore cannot judge if it is my mistake with patching/compiling/copying, the special properties of dCore-Bionic or the driver itself causing this problem. Any thoughts or ideas? Could somebody provide me with a working version of these files to compare?

xanum, does your HP 2133 have BIOS version F.02?
Yesterday, I spent several hours with a friend of mine who helps me reproduce various issues with OpenChrome (he brought his own Wyse X90L and several HP 2133s), and he told me that he has one HP 2133 that exhibits this issue.
He did say that it has BIOS version F.02.
My HP 2133 has BIOS version F.06 (last official version) and it is quite possible this is why you have the VGA connector detection anomaly.
Obviously, BIOS version F.06 does not trigger this issue or I would have done something already.
I believe the VGA BIOS code changed between F.02 and F.06.
I will meet my friend this Saturday and we plan to tackle this issue.

sm8ps, sorry to hear that things are not working.
Can you upload your Xorg.0.log so that I have some idea what is going on?
I have personally confirmed that HP 2133 1280 x 768 FP edition works on Xubuntu 18.04, but the initial installation is somewhat tricky.
If I remember it correctly I had to disable VESA and disable mode setting during installation for it to just install.
I do not use Xubuntu 18.04 at all due to the Eclipse IDE 3.8 and OpenJDK 8 breakage issue that has not been resolved, and I doubt it will ever get fixed since Canonical people rarely fix issues after the software release even for an LTS version.


(In reply to sm8ps from comment #20)
> Unfortunately, I am not getting anywhere here so I would be very thankful
> for some guidance and help! I cloned version 0.6.182 from Github and applied
> the patch to it. Then I compiled it on a machine with Ubuntu 16.04. 
> 
> Afterwards, I copied the files /usr/lib/i386-linux-gnu/libchromeXvMC*.so*
> and /usr/lib/xorg/modules/drivers/openchrome_drv.so in place on the HP Mini
> 2133 which runs dCore-Bionic, a variant of Tinycore Linux using Ubuntu
> Bionic packages. 
> 
> The files are the relevant ones from the Ubuntu package
> xserver-xorg-video-openchrome. The Xorg is version 1.19.6 and version 0.6.0
> from the Ubuntu Bionic package works but obviously uses the wrong screen
> resolution.
> 
> The result after issuing startx is an utterly broken system that does not
> react to anything but the system request keys. I am no expert in any of this
> by far and therefore cannot judge if it is my mistake with
> patching/compiling/copying, the special properties of dCore-Bionic or the
> driver itself causing this problem. Any thoughts or ideas? Could somebody
> provide me with a working version of these files to compare?

Kevin, I confirm that I have firmware F.06
This are the numbers from my BIOS screen:

Product Name: HP 2133
Processor Type: VIA C7-M Processor 1200Mhz
Processor Speed: 1200Mhz
Total Memory: 2048Mb
BIOS Version: F.06
KBC Version: 07.17
VBIOS Version: 02.08

I'll be watching this thread on saturday if you need assistance.

sm8ps: I suggest that you compile the driver in the hpmini itself, and install using 'make install', so all the dependencies are the same and the binaries are copied correctly, including some symlinks done by the make scripts

Best regards

(In reply to Kevin Brace from comment #22)
> sm8ps, sorry to hear that things are not working.
> Can you upload your Xorg.0.log so that I have some idea what is going on?
> I have personally confirmed that HP 2133 1280 x 768 FP edition works on
> Xubuntu 18.04, but the initial installation is somewhat tricky.
> If I remember it correctly I had to disable VESA and disable mode setting
> during installation for it to just install.
> I do not use Xubuntu 18.04 at all due to the Eclipse IDE 3.8 and OpenJDK 8
> breakage issue that has not been resolved, and I doubt it will ever get
> fixed since Canonical people rarely fix issues after the software release
> even for an LTS version.

Did I mention that I am not very experienced in these matters? Literally in the middle of sleep it occurred to me that compiling on a 64-bit machine is no good for a 32-bit one like the HP 2133. I wanted to correct my statement as first thing this morning but you beat me to it.

So thanks for the comment and sorry for the noise! I shall try again on the Mini and get back with my results.

HOORRAY! The patched version 0.6.182 does work beautifully here! I have got an auto-hiding LX-panel which works perfectly well. Since dCore is a single-user system there is no display manager nor any other type of login, so I would not expect to see the flickering as described by xanum.

I just tested suspending and hibernating via pm-utils and they both worked without a flaw. Many, many thanks for your continued efforts, Kevin! 

This is really making the maximum out of the mini. I bought this little machine second-hand because I really like its keyboard for typing while on the way but of course I need to see all of the page that I am writing on.

BTW, I have exactly the same versions as xanum for the BIOS:
> Product Name: HP 2133
> Processor Type: VIA C7-M Processor 1600Mhz
> Processor Speed: 1600Mhz
> Total Memory: 2048MB
> BIOS Version: F.06
> KBC Version: 07.17
> VBIOS Version: 02.08

Let me know if I can assist with anything!

Created attachment 143167 [details] [review]
Detect VGA via I2C bus probing

This patch will change the analog (VGA) detection method to I2C bus probing rather than connector detection.
The patch causes a false positive detection of analog (VGA) when scanning for the first time, but subsequent detections appear to be correct.
Like the 1024 x 600 FP patch, it is a temporary solution mainly for affected users.

xanum, try the new patch I just uploaded to change the VGA detection method.
This should eliminate the false positive detection of VGA, and that should set the FP screen position correctly.
There is still an issue with this patch (i.e., initial false detection of VGA), so it has not been pushed into the upstream repository yet.
It is meant to be a short term temporary fix before more permanent solution can be found.


(In reply to xanum from comment #16)
> Created attachment 143115 [details]
> Xorg Log from patched openchrome 0.6.181
> 
> I have compiled the 0.6.181 driver with your patch in my 1024x600 hp mini
> and installed using 'make install'
> 
> After the reboot, the screen resolution is correctly set to 1024x600, no
> flicker or any other visible problem. Also the standby resume works OK. I'm
> attaching the Xorg log.
> 
> But I see the following problem with the bottom panel: 
> 
> I'm using LXDE with xdm for the login page, also I have a task bar of 50
> pixels high with transparency over a standard LXDE wallpaper. After the
> login page, the taskbar is rendered correctly, but after a few seconds, the
> task bar flickers and the wallpaper seems out of sync in the 24 last pixel
> rows of the screen. Also if I log out and return to the login screen, is
> rendered in a 1024x576 screen and the last 24 pixel rows remain with the
> LXDE wallpaper. In the next attachements I show screenshots with the normal
> screen and the unusual one.
> 
> From reviewing the Xorg Log, I see that the VGA output is detected as
> connected and is set to a 1024x576 (exactly the 24 pixel rows that are the
> problem). I don't have any monitor connected to the VGA output. Could be
> this the problem?
> 
> Best regards

Just to add a few more things about the VGA I2C bus probing issue, it appears that some HP 2133s exhibit this issue and some don't.
A friend of mine has 5 HP 2133s and he told me some of them exhibit the VGA connector issue and some don't.
It appears that this is not really a BIOS version issue and it appears to be a hardware lot issue.
May change the VGA detection method to a different scheme (i.e., older scheme used for the stock Version 0.6) since this I2C probing method appears to be less than reliable method of detecting the presence of VGA.

Again, apply the patch from /xf86-video-openchrome.

patch -p 1 < ("Name of the patch")

Patch should reside inside /xf86-video-openchrome.
The first patch and second patch should be able to coexist, so you can apply 2 patches to the existing Version 0.6.181 or 0.6.182.

Created attachment 143168 [details]
Xorg.log with second Patch

Kevin, thank you very much for your passionate job with this netbooks and the openchrome driver.

I applied the second patch to my already patched version 0.6.181.

The result is that the task bar is rendered correcly and the VGA por is detected as disconnected. Everything seems to be ok now. I'm including the Xorg log for your verification.

Congratulations and my best regards.

After physically breaking the connector from the SATA-device to the mainboard, I could obviously not use the Mini anymore. Now I have it fixed and all is well again. I did not recall the state of affairs with the video driver and was delighted to see everything (!) working. Thanks again for your dedicated work, Kevin!

PS: setting status to RESOLVED/FIXED