[07:54] <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:55] <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:56] <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:57] <alkisg> Would `find /sys/ -name boot_vga` show me the path I'm interested in?
[07:58] <tjaalton> probably not the best place to ask :)
[07:59] <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
[08:00] <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:03]  * alkisg tries: cat $(find /sys/devices -name boot_vga -printf %h)/uevent
[08:10] <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:11] <alkisg> In all the other 20 systems, no problems whatsoever :)
[10:00] <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:01] <tjaalton> trident doesn't have a kms driver, not sure tridentfb makes anything better
[10:03] <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:06] <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:07] <tjaalton> if you have tridentfb loaded the it's probably fbdev on x
[10:09] <alkisg> http://paste.debian.net/413858/
[10:10] <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:11] <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 
[11: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:12] <alkisg> ...unfortunately metacity can't start under tridentfb, so... unusable :D
[11:52] <alkisg> Same for s3fb, it's 10 times faster than vesa, but crashes metacity
[11:54] <tjaalton> why don't you have x-x-v-trident installed?
[12:53] <alkisg> Thanks for the hint, I thought all of the x-x-v* were installed by default but apparently they aren't, installing...
[12:54] <tjaalton> only for kms-capable hw, plus fallback drivers
[12:56] <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:57] <tjaalton> all hw without a kms driver is obsolete :)
[16:14] <alkisg> Do I need to have xserver-xorg-legacy installed to run with non-kms drivers?
[16:26] <tjaalton> yes
[16:28] <alkisg> ty, installing... (maybe those legacy drivers should depend on it?)
[16:34] <tjaalton> maybe
[18:57] <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:59] <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...
[19:13] <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:19] <ricotz> tjaalton, hi, I wondering why intel-gpu-tools is not maintained by xorg team
[19:20] <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:21] <ricotz> oh, I misread that then
[19:21] <ricotz> there is 1.14 release
[19:23] <tjaalton> let's update it then
[19:28] <ricotz> tjaalton, might require python-docutils and libxv-dev
[19:29] <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:30] <tjaalton> and built too
[19:30] <ricotz> rst2man
[19:30] <ricotz> in a clean chroot? ;)
[19:30] <tjaalton> yes
[19:30] <tjaalton> sbuild
[19:31] <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:32] <ricotz> checking for rst2man... no
[19:32] <ricotz> checking for OVERLAY_XVLIB... no
[19:33] <tjaalton> those are not new things
[19:35] <ricotz> I warned you though ;)
[19:37] <tjaalton> there is no rst2man
[19:37] <tjaalton> btw
[19:38] <ricotz> python-docutils: /usr/share/docutils/scripts/python2/rst2man
[19:38] <tjaalton> oh sorry
[19:38] <tjaalton> riiht
[19:38] <tjaalton> +g
[19:49] <tjaalton> intel-gpu-overlay isn't installed, needs manual handling
[19:50] <tjaalton> and it's only built on x86
[19:51] <ricotz> only on x86?
[19:52] <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:53] <tjaalton> 1.14 checks the arch before checking for xvlib
[19:54] <ricotz> https://launchpadlibrarian.net/247418929/buildlog_ubuntu-xenial-amd64.intel-gpu-tools_1.14+git20160310.3e2443f8-0ubuntu1~16.04~ricotz1_BUILDING.txt.gz
[19:58] <tjaalton> x86 archs so _64 too
[19:59] <tjaalton> anyway, since it actually is installed that means I don't need to adjust anything
[20:00] <tjaalton> and it already was built just without xvlbi
[20:00] <tjaalton> -lib
[20:00] <tjaalton> bah
[22:30] <furkan> tjaalton: did you notice that some fonts look sort of bold/fuzzy after upgrading to Xorg 1.18?
[22:32] <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:33] <furkan> for the dropdown menus, i wonder if it's because the 2 strings are being rendered on top of each other
[22:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <furkan> ok actually i had an update to freetype as well
[22:40] <tjaalton> try reverting that
[22:41] <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:42] <furkan> yeah actually i was using a mirror that was out of date
[22:43] <furkan> i had picked a mirror that was nearby
[22:44] <furkan> then realized today that i wasn't getting the xorg update so i switched to a different one
[22:46] <furkan> ok reverted back to libfreetype6_2.5.2
[22:47] <furkan> will see what happens
[22:48] <furkan> ok yeah, still the same problem
[22:49] <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:50] <furkan> packages which could have contributed
[22:54] <tjaalton> test a daily live that's old enough
[22:58] <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:59] <furkan> oh great, yeah it should be
[23:17] <furkan> ok it works fine with 20160307
[23:17] <furkan> i guess after 2 years, it's time for a clean installation
[23:19] <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:20] <furkan> i guess this time i'll stick with 16.04 for as long as i can
[23:29] <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:30] <furkan> ok yeah it does (just checked the manifest)
[23:31] <furkan> i'll try that out to make sure that it's not a problem with my configuration