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