| === tjaalton_ is now known as tjaalton | ||
| alkisg | Hi, I'm a developer of a software called epoptes.org. At some dialog I want to display to the user something like: | 07:54 |
|---|---|---|
| alkisg | VGA card: i915 [15ad:0405] | 07:54 |
| alkisg | I.e. the driver that manages the card, and its pci-id, if it exists (I think e.g. in raspberry pi it doesn't exist). | 07:54 |
| alkisg | What's the best way to get that info via shell, even if xorg isn't running? Currently I'm using lspci, but it's not doing a very good job... | 07:54 |
| alkisg | I was thinking of checking something under /sys | 07:54 |
| alkisg | /sys/devices/pci0000:00/0000:00:0f.0# cat uevent | 07:55 |
| alkisg | DRIVER=vmwgfx | 07:55 |
| alkisg | PCI_CLASS=30000 | 07:55 |
| alkisg | PCI_ID=15AD:0405 | 07:55 |
| alkisg | That would be fine for my needs, but I'm not sure which /sys path to check there, it's too different in various systems that I check | 07:56 |
| alkisg | Would `find /sys/ -name boot_vga` show me the path I'm interested in? | 07:57 |
| tjaalton | probably not the best place to ask :) | 07:58 |
| tjaalton | but that might be a start | 07:59 |
| alkisg | Thank you tjaalton, I'll test that in 20-30 systems and see if it's solid enough | 07:59 |
| tjaalton | and then you get a hybrid | 07:59 |
| tjaalton | where it doesn't necessarily show what you mean | 08:00 |
| alkisg | I don't mind if it shows the wrong vga in multi-vga systems | 08:00 |
| tjaalton | k | 08:00 |
| * alkisg tries: cat $(find /sys/devices -name boot_vga -printf %h)/uevent | 08:03 | |
| alkisg | One problem only so far, under virtualbox, uevent doesn't have a DRIVER= line.... while `lspci -nn -k | grep -A 2 VGA` does show "Kernel modules: vboxvideo". | 08:10 |
| alkisg | In all the other 20 systems, no problems whatsoever :) | 08:11 |
| alkisg | I'm testing with an ancient trident card under 16.04. I don't get a DRIVER= line in the uevent file and Xorg.7.log tells me that it couldn't load the "trident" module. | 10:00 |
| alkisg | Then I run "modprobe tridentfb" and I do get a DRIVER line etc. | 10:00 |
| alkisg | Questions... | 10:00 |
| alkisg | 1) Does that mean that no drivers were managing the card until I ran modprobe tridentfb? | 10:00 |
| alkisg | 2) Should I expect the card to work better after modprobe tridentfb? | 10:00 |
| alkisg | 3) Should I put that modprobe tridentfb somewhere in e.g. /etc/modules so that it's automatically loaded on boot? | 10:00 |
| tjaalton | trident doesn't have a kms driver, not sure tridentfb makes anything better | 10:01 |
| alkisg | So which module makes that card work by default, is it modesetting_drv? | 10:03 |
| alkisg | fbdev? | 10:03 |
| alkisg | vesa? | 10:03 |
| alkisg | ...all of the above? :D | 10:03 |
| tjaalton | vesa | 10:06 |
| tjaalton | check the xorg log | 10:06 |
| alkisg | It reports all those 3 | 10:06 |
| tjaalton | modesetting only loads on drivers that do kms | 10:06 |
| tjaalton | look closer | 10:06 |
| alkisg | looking... :) | 10:06 |
| tjaalton | if you have tridentfb loaded the it's probably fbdev on x | 10:07 |
| alkisg | http://paste.debian.net/413858/ | 10:09 |
| alkisg | I'm still not sure... in this log, I haven't loaded tridentfb | 10:10 |
| tjaalton | vesa | 10:10 |
| alkisg | And I see all of the 3 above | 10:10 |
| tjaalton | and modesetting & fbdev are unloaded | 10:11 |
| tjaalton | so vesa remains | 10:11 |
| alkisg | So it tries the modules in turn, and keeps one of them... | 10:11 |
| alkisg | Thank you very much tjaalton, that cleared some things for me | 10:11 |
| alkisg | x11perf -putimagexy500 results: 54 rep/sec on tridentfb, 6 rep/sec on vesa | 11:11 |
| alkisg | On such slow PCs it does make the difference of "usable vs unusable" | 11:11 |
| alkisg | ...unfortunately metacity can't start under tridentfb, so... unusable :D | 11:12 |
| alkisg | Same for s3fb, it's 10 times faster than vesa, but crashes metacity | 11:52 |
| tjaalton | why don't you have x-x-v-trident installed? | 11:54 |
| === yofel_ is now known as yofel | ||
| alkisg | Thanks for the hint, I thought all of the x-x-v* were installed by default but apparently they aren't, installing... | 12:53 |
| tjaalton | only for kms-capable hw, plus fallback drivers | 12:54 |
| alkisg | That epoptes dialog where we're showing the client info is a very nice place to notify sysadmins about obsolete hardware or missing drivers etc | 12:56 |
| alkisg | I'll see to it that we make it very visible when a driver is missing | 12:56 |
| tjaalton | all hw without a kms driver is obsolete :) | 12:57 |
| alkisg | Do I need to have xserver-xorg-legacy installed to run with non-kms drivers? | 16:14 |
| === JanC_ is now known as JanC | ||
| tjaalton | yes | 16:26 |
| alkisg | ty, installing... (maybe those legacy drivers should depend on it?) | 16:28 |
| tjaalton | maybe | 16:34 |
| alkisg | Meh, the big difference in putimage was due to "modprobe tridentfb" making xorg start with 8bpp as the default, not 24bpp... | 18:57 |
| alkisg | After forcing 24bpp, the putimage results are similar with or without tridentfb (and metacity etc are much more stable) | 18:57 |
| alkisg | It does sound lame to have 0.7 putimages / second in e.g. tnt vanda though, the card's bandwidth should be hundreds of times faster than that... | 18:59 |
| alkisg | trident: 8bpp => 50 putimage/sec, 16bpp => 20 putimage/sec, 24 bpp => 6 putimage/sec | 19:13 |
| alkisg | With 16bpp it's not crashing and it's fast enough to be usable | 19:13 |
| ricotz | tjaalton, hi, I wondering why intel-gpu-tools is not maintained by xorg team | 19:19 |
| tjaalton | ricotz: what do you mean? | 19:20 |
| ricotz | this package https://packages.qa.debian.org/i/intel-gpu-tools.html | 19:20 |
| tjaalton | Maintainer: Debian X Strike Force <debian-x@lists.debian.org> | 19:20 |
| tjaalton | hmm maybe mine is old | 19:20 |
| ricotz | oh, I misread that then | 19:21 |
| ricotz | there is 1.14 release | 19:21 |
| tjaalton | let's update it then | 19:23 |
| ricotz | tjaalton, might require python-docutils and libxv-dev | 19:28 |
| tjaalton | new build-deps? | 19:29 |
| ricotz | tjaalton, yes, but I am looking at git master | 19:29 |
| tjaalton | configure at least passed fine | 19:29 |
| tjaalton | and built too | 19:30 |
| ricotz | rst2man | 19:30 |
| ricotz | in a clean chroot? ;) | 19:30 |
| tjaalton | yes | 19:30 |
| tjaalton | sbuild | 19:30 |
| ricotz | the manpages are not built without rst2man | 19:31 |
| tjaalton | -rw-r--r-- root/root 641 2016-03-10 21:30 ./usr/share/man/man1/intel_aubdump.1.gz | 19:31 |
| tjaalton | bollocks :) | 19:31 |
| ricotz | hmm, https://launchpadlibrarian.net/247417011/buildlog_ubuntu-xenial-amd64.intel-gpu-tools_1.14+git20160310.3e2443f8-0ubuntu1~16.04~ricotz0_BUILDING.txt.gz | 19:31 |
| ricotz | checking for rst2man... no | 19:32 |
| ricotz | checking for OVERLAY_XVLIB... no | 19:32 |
| tjaalton | those are not new things | 19:33 |
| ricotz | I warned you though ;) | 19:35 |
| tjaalton | there is no rst2man | 19:37 |
| tjaalton | btw | 19:37 |
| ricotz | python-docutils: /usr/share/docutils/scripts/python2/rst2man | 19:38 |
| tjaalton | oh sorry | 19:38 |
| tjaalton | riiht | 19:38 |
| tjaalton | +g | 19:38 |
| tjaalton | intel-gpu-overlay isn't installed, needs manual handling | 19:49 |
| tjaalton | and it's only built on x86 | 19:50 |
| ricotz | only on x86? | 19:51 |
| ricotz | intel-gpu-tools: /usr/bin/intel-gpu-overlay on x86_64 | 19:52 |
| ricotz | (maybe a fixed buildsys problem) | 19:52 |
| tjaalton | hmm | 19:52 |
| tjaalton | 1.14 checks the arch before checking for xvlib | 19:53 |
| ricotz | https://launchpadlibrarian.net/247418929/buildlog_ubuntu-xenial-amd64.intel-gpu-tools_1.14+git20160310.3e2443f8-0ubuntu1~16.04~ricotz1_BUILDING.txt.gz | 19:54 |
| tjaalton | x86 archs so _64 too | 19:58 |
| tjaalton | anyway, since it actually is installed that means I don't need to adjust anything | 19:59 |
| tjaalton | and it already was built just without xvlbi | 20:00 |
| tjaalton | -lib | 20:00 |
| tjaalton | bah | 20:00 |
| furkan | tjaalton: did you notice that some fonts look sort of bold/fuzzy after upgrading to Xorg 1.18? | 22:30 |
| furkan | https://www.dropbox.com/s/mbl5z6y4zqtplpe/fuzzyfont1.png?dl=0 | 22:32 |
| furkan | i just upgraded and restarted my PC | 22:32 |
| furkan | the font on the buttons is messed up | 22:32 |
| furkan | and "60 Hz", and "Aperture Priority Mode" | 22:32 |
| furkan | for the dropdown menus, i wonder if it's because the 2 strings are being rendered on top of each other | 22:33 |
| tjaalton | probably freetype update breaking it | 22:34 |
| furkan | because when i click on the dropdown | 22:34 |
| furkan | and the choices appear, the fonts look normal | 22:34 |
| furkan | seems to happen with dropdowns and buttons | 22:34 |
| furkan | same thing w/ calculator | 22:34 |
| tjaalton | on intel hw? | 22:35 |
| furkan | radeon | 22:35 |
| tjaalton | k | 22:35 |
| tjaalton | file a bug | 22:35 |
| tjaalton | actually no | 22:35 |
| tjaalton | this is freetype | 22:35 |
| furkan | do you see the same thing in calculator? | 22:36 |
| furkan | if you switch to scientific mode you get the dropdown menus for degrees/radians | 22:36 |
| furkan | when you click the dropdown and the choices appear, the fonts are normal | 22:36 |
| furkan | but after you select one, it goes fuzzy | 22:36 |
| tjaalton | file a bug against freetype | 22:37 |
| furkan | alright | 22:37 |
| tjaalton | unless there is already | 22:37 |
| tjaalton | i use a custom build to revert a change | 22:37 |
| furkan | xorg 1.18 just hit yesterday | 22:38 |
| furkan | so it might not have been noticed by many people yet | 22:38 |
| tjaalton | it's not caused by it | 22:38 |
| furkan | i mean the bug itself could be in freetype, but it must have been triggered by the xorg update because that's what i just updated | 22:39 |
| furkan | ok actually i had an update to freetype as well | 22:40 |
| tjaalton | try reverting that | 22:40 |
| tjaalton | sounds like you haven't updated in quite a while then | 22:41 |
| tjaalton | https://lists.ubuntu.com/archives/xenial-changes/2016-February/007209.html | 22:41 |
| furkan | yeah actually i was using a mirror that was out of date | 22:42 |
| furkan | i had picked a mirror that was nearby | 22:43 |
| furkan | then realized today that i wasn't getting the xorg update so i switched to a different one | 22:44 |
| furkan | ok reverted back to libfreetype6_2.5.2 | 22:46 |
| furkan | will see what happens | 22:47 |
| furkan | ok yeah, still the same problem | 22:48 |
| furkan | actually in january or february i had added the x-staging ppa to try out xorg 1.18, and i had noticed this then as well | 22:49 |
| furkan | i dunno if there are any other packages that got pulled down from that ppa | 22:49 |
| furkan | packages which could have contributed | 22:50 |
| tjaalton | test a daily live that's old enough | 22:54 |
| furkan | like a daily live CD? | 22:58 |
| tjaalton | yes | 22:58 |
| furkan | is there an archive of those? | 22:58 |
| tjaalton | http://cdimages.ubuntu.com/daily-live/ | 22:58 |
| tjaalton | 20160307 should be old enough | 22:58 |
| furkan | oh great, yeah it should be | 22:59 |
| furkan | ok it works fine with 20160307 | 23:17 |
| furkan | i guess after 2 years, it's time for a clean installation | 23:17 |
| furkan | i've been upgrading releases since 14.04, there must be dirty config files that have been left over along the way or something | 23:19 |
| furkan | after that last dist-upgrade, my volume buttons don't work at all, even after a fresh boot | 23:19 |
| furkan | but they worked with the live CD | 23:19 |
| furkan | i guess this time i'll stick with 16.04 for as long as i can | 23:20 |
| furkan | tjaalton: i just realized i totally confused myself - the whole point of trying the older image was to verify the absence of the bug | 23:29 |
| furkan | does the 20160310 build contain xorg 1.18? | 23:29 |
| furkan | ok yeah it does (just checked the manifest) | 23:30 |
| furkan | i'll try that out to make sure that it's not a problem with my configuration | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
