|
Description
Eric
2016-02-23 06:35:03 UTC
Ok, so I plugged back in the DVI cable to do more tests and I got a mirrored X display on the DVI port. Vector: Use DVI-VGA "Y", unplug DVI, boot system W/VGA connected, wait for X, plug in DVI, Get picture on both. ARandR only shows the VGA is active. Created attachment 121912 [details]
Xorg after activating DVI and playing around with missing mouse cursor
Ok, so if you next goto ARandR (Maximize window for later steps) and click "Outputs> DVI-1> Active" and click apply (green checkmark) the then active DVI screen goes to sleep and the mouse cursor goes away on the VGA screen. If you maximized the window you can play around the top left corner or use Alt-o to get the menu down and uncheck "Outputs> DVI-1> Active" (blindly use the mouse, not the keyboard!) and apply, and then play around, I don't know if it's time, or clicks or what but you CAN get the cursor to come back. Twice I blindly rammed it into the top left corner and clicked and it just came back. I also tried "Alt-o> mouse over VGA-1> orientation> inverted" (the only setting that doesn't crash X). Can't replicate the mouse re-appearing, but I have done it more than once while typing this. I'm including the Xorg.0.log from right now. I hope you are able to follow this and that it helps. Hi Eric,
I will say that it will probably take some time to fix your bug.
At this pace, I will guess that OpenChrome Version 0.3.5 will likely have the bug fix you are asking for.
That being said, the bug you are describing sounds very similar to the bug I was trying to fix until recently.
For a while, I have been trying to fix a bug with standby mode resume bug OpenChrome currently suffers from if I am using a laptop with an LCD screen.
I actually work on OpenChrome development in the very laptop I am having this issue.
Eventually, I pinpointed the bug to several internal registers getting the settings changed (or lost) if the computer resume from standby.
However, this fix has not been committed due to the mouse cursor getting lost completely if I only use LCD.
Until the mouse cursor is restored completely, I really cannot commit the change.
However, I eventually discovered that if I turn on external VGA after resume (by using a screen resolution utility that comes with Lubuntu) or using VGA simultaneously when I resume, the mouse cursor is displayed correctly on the LCD.
The problem with OpenChrome code is that the previous developers did not really care too much about code maintainability and fixing bugs, and the code is truly a mess at this point.
I am little by little trying to clean it up, but this will take a lot of time to accomplish (i.e., will likely require hundreds of code commits).
Please be patient because I will devote more time resources on fixing your bug after I fix the DVI related bugs I am trying to fix right now (see Bug 91966) before Version 0.3.4 release.
Hi Eric, Can you possibly try out the latest code over at the OpenChrome repository? Some improvements were made in the DVI related handling, although I will imagine that the code is still less than perfect. I currently do not have a fully functional computer with DVI that uses an external DVI transmitter chip on the motherboard (i.e., it is called VT1632A chip). Let me know what happens with the following configurations - DVI from DVI connector - VGA coming out of DVI to VGA adapter or DVI and VGA "Y" cable Hi Eric, One question to ask about your Linux distribution version. Which Linux are you using? I see your log and found: [ 1197.389] (II) CHROME(0): [drm] via interface version: 2.11.1 [ 1197.389] (II) CHROME(0): DRI 1 api supported Which kernel are you using? It seems that your kernel supports DRI1. Thanks, Frank (In reply to HuangRan from comment #6) > Hi Eric, > > One question to ask about your Linux distribution version. Which Linux are > you using? I see your log and found: > > [ 1197.389] (II) CHROME(0): [drm] via interface version: 2.11.1 > [ 1197.389] (II) CHROME(0): DRI 1 api supported > > Which kernel are you using? It seems that your kernel supports DRI1. > > Thanks, > Frank I check my Ubuntu 12.04 installation on my VX900 platform and the default kernel is 3.13. And I found drm.ko and via.ko modules under /lib/modules directory, but they are not loaded which leads the result that current OpenChrome have no DRI supported. Right now I am compiling the kernel 3.xx to see if my compiled kernel can make drm.ko and via.ko to be loaded. Thanks, Frank Tested with current openchrome as of this date Current setup: Wyse Vx0LE lspci shows: [S3 Unichrome Pro] (rev 01), Dual HP LP2065 4:3 monitors, one DVI mode, one VGA mode (DVI/VGA "Y" adapter) 1600x1200 60hz. Kernel 3.2.0-101-generic Previously when you ONLY had the VGA connected, it would boot fine with mouse cursor present. When testing with the recent openchrome, the mouse cursor is not present when booted with ONLY the VGA connected. ARandR shows a NEW Output LVDS-1 as active. If you fool around till you can uncheck "Outputs> LVDS-1> Active" and Apply, you get the mouse back. LVDS-1 only haS 1 resoulution, 1600x1200. This board has some un-populated connector pads on it. I don't know if it is a false detection or if the board has some un-used hardware on it. When booted with BOTH VGA and DVI connected, it behaves as it did with previous versions as originally described, except that the LVDS-1 now shows up, but NOT "active" Created attachment 122398 [details]
Xorg.log after booting with only VGA connected
This is current 3/17/16 openchrome where the LVDS showed up
Created attachment 122399 [details]
Xorg.0.log file after booting with BOTH VGA and DVI
LVDS also shows up here
Created attachment 122400 [details]
Screenshot showing LVDS Output
(In reply to Eric from comment #8) > Tested with current openchrome as of this date > Current setup: Wyse Vx0LE > lspci shows: [S3 Unichrome Pro] (rev 01), > Dual HP LP2065 4:3 monitors, one DVI mode, one VGA mode (DVI/VGA "Y" > adapter) 1600x1200 60hz. > Kernel 3.2.0-101-generic Seems your kernel is 3.2.0-101-generic, which Linux distribution version are you using(Ubuntu/Lubuntu/???)? Thanks, Frank Hi Eric, I saw you reported another xrandr bug in 94258. So do you use Lubuntu 12.04 for this bug report too? And can you let me know how you make lubuntu 12.04 installed on your Wyse V90LE platform? I do have purchased a Wyse V90LEW thin client and can not install Ubuntu/Lubuntu 12.04 on it. I attached two pictures for your reference to see if I have the same platform as yours. Thanks, Frank Created attachment 122412 [details]
Wyse V90LE-top
Created attachment 122413 [details]
Wyse V90LE-below
(In reply to HuangRan from comment #15) > Created attachment 122413 [details] > Wyse V90LE-below I attached it with text/plain, how to change it to image/jpeg? Thanks, Frank Yes, your V90LEW looks just like mine, black too. Right now, my Vx0LE (128MB flash, upgraded to 1GB ram) is running Lubuntu 12.04 installed onto a Lexar 16GB TwistTurn USB JumpDrive. I installed from a USB-CD drive from the Lubuntu 12.04 Desktop CD. The machine is painfully slow with everything installed. I recommend a USB drive with a LED on it to show activity. I even added noatime and nodiratime to fstab and turned of journaling and it's still very slow to respond. I tried the minimal install CD and the Server install CD, but those both hung during installation. My Linux Guru friend helped me to make a stripped down install, based off Ubuntu with IceWM, fits onto a 2GB flash drive/microSD card/DOM. Runs like lightning. I have it installed on the Cx0 and Xn0l (on upgraded internal 2GB DOM's). Soon we will get it set up on the Vx0 too. (In reply to Eric from comment #8) Hi Eric, > Tested with current openchrome as of this date > Current setup: Wyse Vx0LE > lspci shows: [S3 Unichrome Pro] (rev 01), > Dual HP LP2065 4:3 monitors, one DVI mode, one VGA mode (DVI/VGA "Y" > adapter) 1600x1200 60hz. > Kernel 3.2.0-101-generic > > Previously when you ONLY had the VGA connected, it would boot fine with > mouse cursor present. > > When testing with the recent openchrome, the mouse cursor is not present > when booted with ONLY the VGA connected. > > ARandR shows a NEW Output LVDS-1 as active. If you fool around till you can > uncheck "Outputs> LVDS-1> Active" and Apply, you get the mouse back. > > LVDS-1 only haS 1 resoulution, 1600x1200. > > This board has some un-populated connector pads on it. I don't know if it is > a false detection or if the board has some un-used hardware on it. > > When booted with BOTH VGA and DVI connected, it behaves as it did with > previous versions as originally described, except that the LVDS-1 now shows > up, but NOT "active" First of all, it appears that there has been some regression in terms of the device driver behavior. I apologize for that. One thing I will say about my commit policy is that I do my own testing with the equipment I have on hand before I do a commit. At least with the netbook laptop I have, DVI is working. However, this DVI is from an integrated TMDS transmitter, and your system has an external TMDS transmitter. I can definitely say that fixing existing OpenChrome bugs is taking a lot longer than I envisioned a month ago. The reality is, OpenChrome code base has many features that are quite undesirable when it comes to maintaining reliable code. For example, the previous developers had a large known device table in the code which was very hard to maintain since it required constant reporting by users to keep it up to date. I discontinued this completely. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=9822064f0cf2675fbaa1390b86a83e5bdd61fbf2 Furthermore, I discontinued legacy user mode setting and VESA BIOS Extension user mode setting. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=d6a65df0e31657495fbdd488c06780b8b33fdccc https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=b48fb4176c96b04f5de8b2ee20f55af404ba0db7 Since there is no known device table anymore, the display resources are now going to be detected automatically (the only exception is OLPC XO-1.5 laptop). OpenChrome does have some code that allows automatic detection of display resources beyond using I2C bus, but it is far from perfect. This is why things regressed in your system. Now that I have gotten rid of "rot" from the code (i.e., known device table, legacy user mode setting, and VBE mode setting), I can now clean up the display resource detection code more freely, and I hope that this will eventually lead to fixing your problem down the road. Hi Eric,
I think I have some explanations on why the cursor does not show up on your screen.
The way VIA Technologies Chrome family of IGP (Integrated Graphics Processor) works is that it contains 2 display controllers internally.
They call this IGA1 and IGA2 (I do not know what IGA stands for.).
Most likely what is going on is that OpenChrome is not really using one of the display controller, but the display controller is still functioning.
What this means is that the display controller hardware is still running, but because OpenChrome is not really using this display controller, it is not turning on the hardware cursor.
The hardware cursor has to be actively managed by OpenChrome like determining the X and Y coordinate on the screen.
Previously, I have been fairly reluctant to make extensive code changes due to the fact that OpenChrome has had many lines of "legacy" code that did not have to be there (i.e., known device table, legacy user mode setting, and VBE mode setting).
Now that stuff is gone, and I have a freer hand in adding more lines of code that does something useful.
It might take a while until the issue can be resolved to your satisfaction, so please be patient.
(In reply to Eric from comment #17) > Yes, your V90LEW looks just like mine, black too. Right now, my Vx0LE (128MB > flash, upgraded to 1GB ram) is running Lubuntu 12.04 installed onto a Lexar > 16GB TwistTurn USB JumpDrive. I installed from a USB-CD drive from the > Lubuntu 12.04 Desktop CD. The machine is painfully slow with everything > installed. I recommend a USB drive with a LED on it to show activity. I even > added noatime and nodiratime to fstab and turned of journaling and it's > still very slow to respond. I tried the minimal install CD and the Server > install CD, but those both hung during installation. > > My Linux Guru friend helped me to make a stripped down install, based off > Ubuntu with IceWM, fits onto a 2GB flash drive/microSD card/DOM. Runs like > lightning. I have it installed on the Cx0 and Xn0l (on upgraded internal 2GB > DOM's). Soon we will get it set up on the Vx0 too. Hi Eric, You can see what my V90LE board looks like. I have attached more pictures for your reference in a private mail. If possible, please attach your board pictures for me to compare. My V90LE has a 1GB memory and 4GB ATA flash hard disk. So I prefer to buy an ATA->CF converter and a 32GB CF card to compose my system. And I believe CF card which is from ATA interface should be quicker than USB drive stick. So what I want to know is how to install Ubuntu/Lubuntu 12.04 on this board which is the first step for me to help on this issue. Attached is the picture when I am trying to install Lubuntu on 4GB ATA flash hard disk. It will stay in this screen for 1 minute and the screen goes to black with no responding. But Ubuntu 10.04 installation on this board is okay. Thanks, Frank Created attachment 122452 [details]
Lubuntu installation
Hi Kevin, (In reply to Kevin Brace from comment #19) > Hi Eric, > > I think I have some explanations on why the cursor does not show up on your > screen. > The way VIA Technologies Chrome family of IGP (Integrated Graphics > Processor) works is that it contains 2 display controllers internally. > They call this IGA1 and IGA2 (I do not know what IGA stands for.). IGA should be VIA's display engine(I asked this from VIA's engineer before). As I worked for RADEON driver, each IGA should has its HW cursor and as you said, the IGA engine do the HW cursor show/hide/content changing. > Most likely what is going on is that OpenChrome is not really using one of > the display controller, but the display controller is still functioning. > What this means is that the display controller hardware is still running, > but because OpenChrome is not really using this display controller, it is > not turning on the hardware cursor. So can I understand that current UMS driver does not enable HW cursor? So why not enable SW cursor instead before HW one is working? Thanks, Frank Hi Eric, (In reply to HuangRan from comment #7) > I check my Ubuntu 12.04 installation on my VX900 platform and the default > kernel is 3.13. And I found drm.ko and via.ko modules under /lib/modules > directory, but they are not loaded which leads the result that current > OpenChrome have no DRI supported. Right now I am compiling the kernel 3.xx > to see if my compiled kernel can make drm.ko and via.ko to be loaded. > > Thanks, > Frank I have found one case that DRI1 is used and drm.ko/via.ko modules are loaded by DDX. That is Xserver 1.11.3 when we do openchrome dep build. You can skip this question now. Thanks, Frank Hi Eric, Sorry for the bug triage to take so long. I recently released OpenChrome Version 0.4.0, and it will be nice if you can try the code with your thin client. Please note that the support for the particular DVI you have (i.e., DVI coming from an external transmitter rather than the graphics itself) has been temporarily disabled due to a release schedule issue. I am hoping at least the VGA will be working again. I think about 2 weeks ago, you noticed a regression of the code (for VGA), and I believe what happened was that I was removing several undesirable legacy features from OpenChrome, and I basically opened a can of worms. Since then, I believe the issue has been resolved, and I hope your VGA is working again. In terms of developer bug triage priority, I will say that fixing the DVI will be the third priority, behind HP T5550 thin client DVI to VGA adapter issue and screen resolution crash bug (Bug 94258 you reported). This is because there has to be some amount of code rewriting to assign the correct display controller in order for DVI to work correctly, and I will guess that this is more difficult than past fixes I have made. Hi Eric, Recently, i've been trying to confirm this bug on Wyse V90LE. I installed Lubuntu-12.04-desktop with the default kernel 3.2.0-23-generic. The monitor is G225HQV (DVI to VGA). I've tried some version of ddx(including revision 8bc53d8 and revision d951436 in your logs). In older versions before revision 7a98f65(Using I2C bus 2 to detect a VGA monitor), VGA doesn't work. But in later versions(like release 0.4.0), VGA works and cursor shows up. Then i added some debug info in some functions to print the register value of Hardware Icon(VIAGETREG(PRIM_HI_POSSTART)). And it turns out that HWCursor works fine. Created attachment 122890 [details]
add debug info in iga1_crtc_set_cursor_position
Created attachment 122891 [details]
Xorg.0.log with custom debug info
Hi Eric, Before the release of OpenChrome Version 0.4.0, I figured out the cause of the functional regression you have reported. I believe this was related to the detection of a LVDS FP (Flat Panel) primarily meant for laptops, and I found ways to automatically detect FPs without interfering with the detection of other display devices like VGA. What I believe happened was that when I moved to all automatic detection of display devices, all devices were running through the code that will detect a FP, and for your particular system, this was causing problems since the previous developers were doing some odd things to "guess" the native screen resolution of the FP. I removed that portion of the code, and found a good way to detect the native screen resolution of the FP before the new release. I will say that you should give the current master branch code a try (Version 0.4.107), and see how it performs. Hi Eric, One more thing. For now, I had to disable the DVI functionality your hardware supports. This is due to the fact that I really needed to release a new version of OpenChrome since Version 0.3.3 had a fatal bug with computers it does not recognize (i.e., systems not registered with its "known device table"), practically all Linux distributions still use Version 0.3.3 (i.e., Fedora, Ubuntu, Debian, etc.). The biggest code change between Version 0.3.3 and Version 0.4.0 is the removal of "known device table" and fixing the regression of DVI to VGA adapter people have reported. I plan to eventually activate the DVI functionality, but it will likely require a complete rewriting of the display resource detection code. This will likely take anywhere from 3 months to 6 months, I will estimate. (In reply to caozong from comment #25) Hi Zong, > Hi Eric, > Recently, i've been trying to confirm this bug on Wyse V90LE. I installed > Lubuntu-12.04-desktop with the default kernel 3.2.0-23-generic. The monitor > is G225HQV (DVI to VGA). I've tried some version of ddx(including revision > 8bc53d8 and revision d951436 in your logs). In older versions before > revision 7a98f65(Using I2C bus 2 to detect a VGA monitor), VGA doesn't work. > But in later versions(like release 0.4.0), VGA works and cursor shows up. > Then i added some debug info in some functions to print the register value > of Hardware Icon(VIAGETREG(PRIM_HI_POSSTART)). And it turns out that > HWCursor works fine. As I have explained here, I think I know the reason why DVI to VGA "broke" with Eric's system setup, and the regression was unintentional. Of course, I did fix the bug before OpenChrome Version 0.4.0 release as you have correctly observed. In general, the hardware cursor works with all UniChrome Pro or later VIA IGP hardware. For UniChrome IGP (pre-UniChrome Pro; CLE266, KM400(A), KN400, and P4M800), OpenChrome appears to be using a software cursor, and there appears to be a mouse cursor rendering bug with Lubuntu 10.04 (Ubuntu 10.04 LTS and Lubuntu 12.04 are okay). UniChrome Pro or later IGPs are not affected by this bug even in Lubuntu 10.04. Eventually, I plan to fix this bug. Current setup: Wyse Vx0LE, Lubuntu 12.04, OpenChrome 0.4.108 Dual HP LP2065 4:3 monitors, one DVI mode, one VGA mode (DVI/VGA "Y" adapter) 1600x1200 60hz. Displays are now mirrored, whatever I see on the VGA screen I also see on the DVI screen at all stages of boot and shutdown, including Ctrl-Alt-F1 to console and Ctrl-Alt-F7 back to X. ARandR only shows VGA-1 under Outputs. Created attachment 122915 [details]
Xorg.0.log from Vx0LE after booting both VGA and DVI "Y" on 0.4.108
Hi Kevin, Thanks for your explaination. I think I have the same problem but in a different situation. I use openchrome KMS driver and DVI port. I'm going to do more test and report a new bug. Hi Eric and Zong, Can you guys try out OpenChrome Version 0.4.179? https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=b57d2f95275f6ef0db098773a48b1cfbb442acac https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=7cb19d9843dcb4cd5107c1a0851403c48b6db6be I did observe correct operation of DVI with Wyse C00X thin client using Puppy Linux 5.7.1. I am hoping it will also work with CN700 chipset + VT1632A. Hi Kevin, I've tried the OpenChrome Version 0.4.179 on KMS and UMS(I renamed drm.ko drm_kms_help.ko and via.ko). Cursor shows up on UMS!! And it works well. But it remain the same on KMS. Setup: Wyse V90LE http://www.parkytowers.me.uk/thin/wyse/vx0/WyseV90LE.shtml Chipset: CN700 System: Ubuntu 12.04 Kernel: linux 3.19 drm-openchrome DDX: xf86-video-openchrome release 0.4.0 Monitor:LEN E2323swA (DVI-D) Created attachment 124496 [details]
Xorg.0.log on 0.4.179 on KMS
Created attachment 124497 [details]
Xorg.0.log on 0.4.179 on UMS
(In reply to caozong from comment #35) Hi Zong, > Hi Kevin, > I've tried the OpenChrome Version 0.4.179 on KMS and UMS(I renamed drm.ko > drm_kms_help.ko and via.ko). Cursor shows up on UMS!! And it works well. But > it remain the same on KMS. > > > Setup: Wyse V90LE http://www.parkytowers.me.uk/thin/wyse/vx0/WyseV90LE.shtml > Chipset: CN700 > System: Ubuntu 12.04 > Kernel: linux 3.19 drm-openchrome > DDX: xf86-video-openchrome release 0.4.0 > Monitor:LEN E2323swA (DVI-D) Someone pointed out a regression I caused with Version 0.4.177 (Bug 96500). This affects monitors with 1920 dots horizontal resolution (i.e., 1920 X 1080) for IGA1. This bug was just fixed. Use Version 0.4.180 or later. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=d234cdf68ea6a27718a948918b3075ad257e8a0f I think for now, by luck, DVI is getting assigned to IGA2, and probably why you did not encounter the bug (The bug only affects IGA1.). Anyway, I am glad that DVI coming out of VT1632A is now working with CN700 chipset. Regarding the cursor bug, I will put more time into it when I start working towards releasing OpenChrome Version 0.6. Right now for Version 0.5, I have a few more things to work on, along with a bug that has become an effective blocker for release of Version 0.5 (Bug 95420). Unfortunately, fixing one bug often takes tremendous amount of concentration depending on how tricky it is to fixing it, and as a result, I have not been able to spend adequate amount of time on helping to fix the OpenChrome DRM / KMS bug you have reported. Current setup: Wyse Vx0LE OpenChrome 4.0.902 Invisible mouse cursor on dual monitors with DVI/VGA "Y" cable. It was just working until I upgraded to 0.4.902. I can't remember what I had before I think it was 0.4.168. I was playing with ARandR and was able to independently change resolutions but the mouse was still a no show. Attached is Xorg.0.log after I changed both resolutions to 1600x1200. Let me know if you need a clean boot one. I'm posting this from said machine with the mouse invisible, I hope I don't wear out my Tab key ;) Created attachment 124690 [details]
Xorg.0.log from 0.4.902 with invisible mouse cursor on dual displays
When booting VGA only, everything seems to be fine. When booting DVI only, screen is corrupted. Nothing I do changes the screen. Power button works to shutdown. Don't know if this helps, but when booting VGA or VGA/DVI the grub boot screen is shown with small letters and lots of space (high resolution text), but when booting from DVI only, the grub boot screen is at a low resolution (like 80x24 text). the Lubuntu splash screen is also low res (larger image), where on the VGA, VGA/DVI it's high res (smaller image) The corrupted screen also seems to be a low res mode, with big pixel lines. I'm including Xorg.0.log from both boots. Created attachment 124691 [details]
Xorg.0.log 0.4.902 VGA only boot
Created attachment 124692 [details]
Xorg.0.log.old 0.4.902 DVI only boot (from failed last boot)
(In reply to Eric from comment #39) Hi Eric, > Current setup: Wyse Vx0LE > > OpenChrome 4.0.902 > > Invisible mouse cursor on dual monitors with DVI/VGA "Y" cable. It was just > working until I upgraded to 0.4.902. I can't remember what I had before I > think it was 0.4.168. > > I was playing with ARandR and was able to independently change resolutions > but the mouse was still a no show. > > Attached is Xorg.0.log after I changed both resolutions to 1600x1200. Let me > know if you need a clean boot one. > > I'm posting this from said machine with the mouse invisible, I hope I don't > wear out my Tab key ;) Although many experiments do fail, I do have an idea for what to try regarding the cursor issue. I will try to get a patch ready in a few hours. Stay tuned. Created attachment 124783 [details] [review] Proposed fix for CN700 IGA2 no cursor Hopefully, this proposed fix will get the cursor working on CN700 chipset. Hi Eric, I had some other thing to do yesterday, so I was not able to upload the patch "within a few hours," but I finally got it uploaded. If there is a problem with video display on the DVI screen for V series thin client, I will have to take a look at the internal VIA IGP registers to see how some of the relevant registers are set up. It is possible I may have to reverse engineer some of the registers back into OpenChrome to get it working for CN700 chipset. Created attachment 124821 [details] [review] Proposed fix for Wyse Vx0 DVI not working This fix make IGA2 to be the source of DVP0 (Digital Video Port 0). This fix is meant to get Wyse Vx0's DVI to work correctly. Signed-off-by: Eric Kudzin <"Eric's e-mail address"> Signed-off-by: Kevin Brace <"Kevin's e-mail address"> On dual displays, the mouse shows up only on the DVI screen. Created attachment 124855 [details]
Xorg.0.log patched with mouse only on DVI (dual screen)
If I use ARandR to move the VGA screen halfway down, overlapping with the DVI, and spin the mouse around the screen, I can see a flicker of the mouse on the VGA screen. If I move it slow, when I cross the top barrier/border of the VGA screen (this is partly down the DVI screen) it appears on the VGA screen, but not at the top, it appears partly down, mirroring its xy position from the DVI screen where it left from. I can move the cursor around on the VGA screen until it intersects with a window border on the DVI screen changing its icon I put the terminal window on the barrier/border and when I cross it the mouse icon, now an I beam, appears on the VGA as an I beam. The I beam appears on the VGA screen, on the background wallpaper below the terminal window, but if I click it clicks inside the terminal This is hard to describe but I hope it helps. If I lower the screen resolution and put the screens one below the other, the mouse transfers from one screen to the other leaving the bottom of one screen and appearing on the top of the other. The half screen mode described in the previous comment, the cursor was always tracking with the DVI screen, it would disappear from the DVI and appear on the VGA, but always at the mirrored XY point (ie: 2 inches down and 3 inches over) Oh, and now the DVI screen shows 1601x1201 on the Vx0, like it does on the Cx0. Booting with VGA only, the mouse appears on VGA. Connecting the DVI and activating it in ARandR causes the mouse to goto the DVI only. Booting with only DVI, the mouse appears on DVI, but if I connect the VGA I CANNOT activate it in ARandR, "Active" is grayed out and can't be selected. Mouse behavior from comment 51: If I lower the screen resolution and put the screens one below the other, the mouse transfers from one screen to the other leaving the bottom of one screen and appearing on the top of the other. ... This no longer works the way it did. When the mouse gets to about 1 inch from the bottom of the top screen it disappears from the top screen and appears in the bottom inch of the bottom screen. It's a false cursor at this point because if I right click it re-appears in the bottom inch of the top window (basically where it should be). If I move it down a bit further and right click it appears on the top of the bottom window (again, where it should be). If the mouse is invisible and it hits a window, when it changes its icon, it will appear. It will also appear if you right click. The above comment 54 is with DVI on top and VGA on the bottom. If you put VGA on top the behavior is the same except that when you goto the bottom 1 inch of the top screen, the mouse still disappears, but there is no false cursor on the bottom screen. If you right click in this zone, the mouse does NOT appear. Hi Eric,
I think CN700 has a hardware level limitation that does not allow simultaneous display of hardware cursors (Note: strictly speaking, VIA calls this hardware icon).
In order to workaround this limitation, you will like to put the following xorg.conf under /etc/X11.
___________________________________________________________________________
Section "Device"
Identifier "openchrome"
Driver "openchrome"
Option "SWCursor" "true"
EndSection
___________________________________________________________________________
This will disable hardware cursor and use software cursor instead.
This should workaround the cursor problem when you are using two monitors.
In the future, software cursor may have to be forced if the user is using two display controllers simultaneously for the older chipsets.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/openchrome/old-bug-database/issues/15. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.