Mouse pointer and graphical issues with Trisquel 6.0
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
I've recently installed the new version of Trisquel (6.0, toutalis), having 5.5 (Brigantia) in a separated partition.
I could only test and install the live operating system when adding the startup option "nomodeset".
After installation I also had to add the "nomodeset" kernal parameter in the boot loader, otherwise I wouldn't be able to login using conventional methods, only using terminal (however, I haven't tried logging in trough it then starting the X server, if I can call it this way).
During the process of setting my new operating system, I noticed that Compiz was installed, so I removed it, and the associated packages, and decided to try the system without the "nomodeset" kernel parameter.
And so I finally passed the login screen. Since the version 5.5 of Trisquel recognizes my video card (using the latest Linux-libre kerel, of course) and has Gallium3D support for it, I checked if the standard kernel does the same, so I went to the system configuration menu and to the detailed section and came to the conclusion that the standard kernel doesn't.
So I decided to install the Linux-libre kernel, just as I did with my other Trisquel partition. It gave me no results, the system continues to not recognize my video card.
Then I reverted to the standard kernel (and so removed all the Linux-libre repositories) and decided to do some graphical tests, I started with Nexuiz, which turned my screen black for some seconds and then, I was back to the login screen.
I checked the output from dmesg, and noticed this:
[ 15.742451] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0000
[ 15.742455] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0040
[ 15.744047] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0000
[ 15.744050] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0040
[ 15.744063] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0040
[ 15.744065] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0000
[ 16.248735] usblp0: removed
[ 16.250418] usblp0: USB Bidirectional printer dev 5 if 0 alt 0 proto 2 vid 0x03F0 pid 0x7904
[ 25.407113] eth0: no IPv6 routers present
[ 64.819350] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0000
[ 64.819354] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0040
[ 64.819373] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0000
[ 64.819377] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0040
[ 64.819396] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0040
[ 64.819399] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0000
[ 64.819457] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0000
[ 64.819460] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0040
[ 64.819507] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0040
[ 64.819510] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0000
[ 64.819568] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0040
[ 64.819571] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0000
[ 64.819583] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0040
[ 64.819586] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0000
[ 64.819598] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0000
[ 64.819601] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0040
[ 64.819626] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0000
[ 64.819629] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0040
[ 64.819640] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0000
[ 64.819643] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0040
[ 64.819654] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0040
[ 64.819657] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0000
[ 64.819694] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0040
[ 64.819697] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0000
[ 64.819708] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0000
[ 64.819711] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0040
[ 64.819724] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0000
[ 64.819727] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0040
[ 64.819752] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0000
[ 64.819755] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0040
[ 105.899273] init: tty1 main process ended, respawning
[ 483.647197] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0040
[ 483.647200] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0040
[ 488.129630] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0040
[ 488.129635] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0040
[ 488.321182] [drm] nouveau 0000:01:00.0: PMFB0_SUBP0: 0x037f0040
[ 488.321188] [drm] nouveau 0000:01:00.0: PMFB0_SUBP1: 0x037f0040
Note: there might have some unnecessary stuff, but I decided not to change it for the sake of transparency.
So I went back to the basic trick of adding the "nomodeset" kernel parameter to the bot loader. And this time, the system recognizes my video card in the detailed section of the system configuration menu, and gives me this information:
VESA: GF108 Board - 1071v0p1.
Then, I decided to test Nexuiz again, and it worked almost smothly, except for the fact that every time an enemy appears in the screen, the game freezes for a second, and the CPU usage goes way up.
Searching in the Internet, I found out that the developers of Nexuiz made it possible for those with high CPU powers to use it (the CPU powers). They did so by using Gallium3D over something called llvmpipe, which I don't know what it is.
So I tried a more valid test, this time with PCSX-R, and everything went ok, the games could be emulated fine.
Notes:
- All the programs were run with minimal-and-yet-playable configuration in windowed mode;
- The output of lspci gives the correct video card name in all the cases, that is:
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 430] (rev a1)
But this is not the main problem.
I noticed that whenever I do an action with the mouse pointer (other than moving it), it disappears and only comes back when I move it.
For daily use it's not a big problem, but when it comes to productivity tasks like image and vector graphics manipulation, it's extremely hard to see the mouse pointer.
Notes:
- The mouse pointer problem only appears when the "nomodeset" kernel parameter is added to the boot loader;
- When going to the system configuration menu, under display configuration (without the "nomodeset" kernel parameter), my monitor is detected as a GSM, and I have more resolutions available. In the other case, it's detected as a laptop display and has just 1024x768 and 800x600 available. This is not a problem for me because I just use 1024x768.
So... Is it possible to fix the mouse pointer problem, or even better, the other problem mentioned in the beginning of this post.
Best regards, ADFENO.
Have a nice day.
Addendum: I can provide more information, if you wish.
Tried this advice? http://nouveau.freedesktop.org/wiki/TroubleShooting
Before you go any further in this post, remember that all attachments here are a result of my system being ran without the "nomodeset" kernel parameter so, in short, with the default kernal parameters.
Notes:
- I tried to preserve the content of the log files, but I had to edit the syslog file. This was necessary because of the fact that I'm not a regular terminal user, so I don't know how to copy a file to another directory and rename it before it gets to the target directory, so I accidentally replaced the first syslog file (the one which is named just as syslog) with the one which was supposed to show the system behavior after running Neverball. So, I had to edit this one to remove the last outputs, and save the result with a new name (syslog), so the output of this file might be inaccurate, sorry.
- From the last note you might wonder why I didn't log in using the login screen. It's because I was afraid that it could add something to the log files, so I just relied with the terminal and the ls, cd mv, nano and cp commands.
I can also get the outputs (don't put words here, it's different from "the same outputs") of the log files when running the system with the "nomodeset" kernel parameter. If you wish so, just tell me.
Best regards, ADFENO.
Have a nice day.
First addendum: Thank you lembas. According to the page you suggested and the Xorg.0.log file, it appears that nouveau is loaded one time, but for other situation it isn't, becuase it is already in use. I'm not good with informations inside log files, so forgive me if I misunderstood it.
Second addendum: The forum renamed the attached file from "Tests without nomodeset.tar.gz" to "Tests without nomodeset.tar_.gz".
Pièce jointe | Taille |
---|---|
Tests without nomodeset.tar_.gz | 618.8 Ko |
Hi everybody,
Yesterday I arranged some time to look further in my problem, so I decided to search for an answer to the mouse flickering problem since I could perfectly live with the VESA module, at least for native video games.
So I came up to this page:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-fbdev/+bug/1034470
One of the comments had something related to the hardware and the software cursor, so I decided that I would try that out, and so I found out that it's possible to determine the type of cursor in the xorg.conf file, which I found in /etc/X11.
So I decided to take some examples to find out in which section I should put the "HWCursor" option. After doing so (setting the option to "true") I removed the "nomodeset" kernel parameter and rebooted the system. Unfortunately, it didn't change anything, so I removed the "HWCursor" option and rebooted the system again.
Since I also have my favorite Trisquel version (which is 5.5, Brigantia) in this computer, I decided to look after its xorg.conf, but I couldn't find it under /etc/X11, so I decided to remove the xorg.conf from version 6.0, but just to be in the safe side, I made a copy of it, which left me with the files xorg.conf~ (this being my copy) and xorg.conf.vesa.
So I rebooted the system and, for my surprise, when I decided to test Neverball, all went well, despite the fact that, under the detailed section of the system configuration, my graphics are still recognized as unknown (this also happens when using HardInfo, which is in the default repositories).
As I said in my previews comments, according to the Nexuiz developers, it can use the CPU power to help in the graphical process, if the CPU supports something which I don't remember correctly. What I do remember is that when I ran Nexuiz on a virtual terminal while the "nomodeset" kernel parameter was kept, the game recognized my CPU capabilities and used Gallium3D over something called lvmpipe.
This time, the situation is different. When I decided to run Nexuiz on a virtual terminal, it used Gallium3D over NVC1 (which is indeed the family of my video card).
In short, I solved two problems, despite knowing the risks:
- The problem which caused my system to return to the login screen when the 3D acceleration was used. Which could be fixed by setting the "nomodeset" kernel parameter in the boot loader (in this case, GRUB).
- The problem with the mouse pointer, which flickered when certain actions were made. Which was caused by the "nomodeset" kernel parameter.
As I said early, I kept a copy of the xorg.conf file which has been deleted. So, just for those interested, it's available as an attachment.
Best regards, ADFENO.
Have a nice day.
Addendum: The forum renamed the attachment "Deleted xorg.conf.txt" to "Deleted xorg.conf_.txt".
Pièce jointe | Taille |
---|---|
Deleted xorg.conf_.txt | 89 octets |
- Vous devez vous identifier ou créer un compte pour écrire des commentaires