01:41 hakzsam_: imirkin, just a reminder for the gl_amd_perfmon series ;)
06:52 LyndaT3: Hi. I've a machine with an Nvidia GT610 video card. I'm trying to get high-res fb output -- full use of my 1920x1080 monitor, with 'smaller text' -- during linux startup/boot console output. At the moment, it's just displaying @ 1024x768, even though: 'cat /sys/class/graphics/fb0/name' -> "nouveaufb", and, 'xrandr --prop' -> "Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384".
06:52 LyndaT3: I've been working through http://nouveau.freedesktop.org/wiki/{KernelModeSetting,TroubleShooting} in attempt to get my desired hi-res output. No luck so far. I'm missing something. Any hints?
06:53 LyndaT3: In one attempt, when I try to set "xrandr --output DVI-D-0 --set 'scaling mode' None", it returns "xrandr --output DVI-D-0 --set 'scaling mode' None" which clearly looks problematic.
06:54 LyndaT3: Oops. returns: "X Error of failed request: BadName (named color or font does not exist)"
06:56 imirkin: LyndaT3: the fact that you're talking about DVI-D-0 suggests to me you're using a very old DDX version, and probably a very old kernel as well
06:58 LyndaT3: imirkin: Hi. Don't know what DDX is (yet). My kernel is: 3.19.2-3.gd8856ce
06:58 imirkin: xf86-video-nouveau
06:59 imirkin: can you pastebin your dmesg, Xorg.0.log, and glxinfo outputs?
06:59 LyndaT3: imirkin: sure, one sec
07:00 LyndaT3: imirkin: wait, there's no X svr installed. it's a server. just talking about console @ boot time.
07:00 imirkin: oh. you were talking about xrandr
07:00 imirkin: can you pastebin your dmesg then?
07:01 LyndaT3: imirkin: I installed only xrandr just because it was mentioned as diagnostic. one sec ...
07:01 imirkin: xrandr is a tool that interacts with the X server
07:03 LyndaT3: imirkin: hm. perhaps I'm confused (likely). it still provides output. anyway, http://pastebin.com/gjhfUxUK
07:04 imirkin: perhaps you have an X server running ;)
07:05 imirkin: based on what i'm reading in there, you should be ending up with a 1920x1080 terminal
07:05 imirkin: is that not the case?
07:05 LyndaT3: imirkin: fwiw, http://pastebin.com/8FF7P9Au
07:06 imirkin: ps auxwwww | grep X
07:06 LyndaT3: ps ax | grep X -> (empty)
07:06 imirkin: should tell you whether you have one running
07:06 imirkin: hmmm.... maybe xrandr reads from drm directly. that'd be a little surprising.
07:06 LyndaT3: ps auxwwww | grep X -> (empty), too
07:07 pq: going over ssh?
07:07 LyndaT3: imirkin: xrandr output -> http://pastebin.com/03DbNepM
07:08 LyndaT3: pq Hi. yes. detecting my local desktop somehow?
07:08 imirkin: ssh X forwarding :) echo $DISPLAY
07:08 imirkin: probably localhost:10.0
07:09 LyndaT3: yep, localhost:10.0. ok, so clearly I'm fubar'ing something. shutting up now, and hoping to learn something :-)
07:09 imirkin: use 'ssh -x' to disable X forwarding
07:09 pq: yup - your xrandr connects to the X running on your local machine, not the one you ssh'd in
07:09 LyndaT3: ok. :0, now
07:10 imirkin: anyhooo... so you're saying that you don't see a 1920x1080 output?
07:10 LyndaT3: imirkin: yes.
07:10 imirkin: how are you determining that?
07:11 LyndaT3: imirkin: sitting in front of the console and staring at it when it boots. "big, fat" text.
07:12 LyndaT3: I have a naive, nagging suspicion this has something to do with UEFI ...
07:12 imirkin: grep . /sys/class/drm/card*-*/modes
07:12 imirkin: nah, nouveaufb takes over from efifb...
07:13 LyndaT3: imirkin: -> http://pastebin.com/rEtUZKsu
07:13 imirkin: any way to check what mode the display is actually detecting?
07:14 LyndaT3: oh. wait. this card's connected to my DVI monitor via HDMI out (HDMI to DVI cable). notice the card ID.
07:15 imirkin: that's not a problem
07:15 LyndaT3: hm. no idea how to check ...
07:15 imirkin: usually there are buttons on the front of monitors that let you see various informations
07:16 LyndaT3: imirkin: huh? sry, i'm being thick. it's a 1920x1080 monitor. shared between this desktop, and 3 other machines, via KVM.
07:17 imirkin: sure, but unless it's from 1800, it's a multi-mode monitor
07:17 imirkin: i.e. i could be feeding a 1024x768 mode to it, and it would display it just fine
07:18 LyndaT3: oh looky! an 'info' button! one sec ...
07:18 imirkin: (pretty sure fixed mode monitors died out by like 1990, if not earlier)
07:18 imirkin: although they're sorta back with LVDS-attached panels and the such
07:19 imirkin: but consumer monitors tend to include hw scalers and whatnot that fix the glitch
07:19 LyndaT3: um. an official 'WTF'? I just switched over the KVM ... and for the 1st time in four days, it's displaying at 1920x1080 -- with my 'goal' small text.
07:19 imirkin: alrighty. problem solved.
07:19 LyndaT3:scratches head
07:20 LyndaT3: well, no ... cosmic-ray-inducced events are not a solution. /me looks for enlightenment & understanding ;-)
07:20 imirkin: note that it will only give you a hi-res console once nouveau loads
07:20 imirkin: which according to your logs, is about 20s into the boot
07:21 imirkin: (yay for systemd and its incredibly fast boots?)
07:21 LyndaT3: imirkin: i'm about to check ....
07:23 imirkin: note that depending the kvm you use, it might be advertising a crappy mode
07:23 imirkin: which is what nouveau will detect when it loads
07:23 imirkin: the fbcon logic is pretty dumb, it doesn't do any adaptive anything
07:23 imirkin: what it detects on load is what you get
07:25 LyndaT3: imirkin: ok. currently @ boot : no more grub menu displayed (will figure that out in a bit); 1st ~30sec are 'large text', screen goes blank for ~5 secs, then repopulates @ hi-res, 'small text'. fwiw, it's a mid-crap DVI -- from IOGEAR. my desktops have no problems with the early/full console @ hi-res. then again, they're all grub-legacy, non-UEFI, consumer/desktop (ASUS) mobos.
07:26 LyndaT3: the server's a Supermicro 'workstation' board. more toys than a 'server' mobo, but missing IMPI.
07:27 imirkin: get the -T series supermicros... the bmc is nice to have in remote situations
07:27 imirkin: er, -F
07:29 LyndaT3: imirkin: yeah, tradeoffs. it's an X10SAT. I wanted the 8 sata ... It's a local server (50 ft from me ...), so didn't particularly care -- on this one. I've AMT, which is convenient. SOL *would* be nice, though. If need be, can add an IMPI card ...
07:30 imirkin: IPMI :)
07:30 LyndaT3: I'm reading up on the fb handoffs ... any way to set that pre-nouveau res? for fbcon, i guess?
07:30 imirkin: nope
07:30 imirkin: you get what you get... probably set by the uefi bootloader
07:30 LyndaT3: imirkin: nah, I *was* referring to the Zulu army ;-)
07:31 imirkin: but note that it might actually set the higher res
07:31 imirkin: and just use a larger font
07:32 LyndaT3: hm. hadn't thought of that ... never have monkeyed with console fonts.
07:33 imirkin: prior to nouveau taking over, you're using efifb
07:33 imirkin: which makes efi service calls to write text to the screen... i think
07:34 LyndaT3: imirkin: fwiw, http://pastebin.com/pghV5ghN
07:35 imirkin: which of course is just info output by the efi driver... who knows what it does behind the scenes
07:36 LyndaT3: imirkin: This is my 1st UEFI install. docs are a bit thin ...
07:36 imirkin: it's exactly the same thing as 'bios', but spelled differently
07:36 imirkin: provides services for the OS to use
07:37 imirkin: initializes things
07:38 imirkin: has a hard requirement on booting off a FAT partition
07:38 imirkin: [oh, and it knows about partitions too]
07:39 LyndaT3: exactly the same? tell that to Xen, atm ;-)
07:40 LyndaT3: i at least turned off SecureBoot. it was making my head hurt.
07:41 specing: it is secure, but not for you
07:42 specing: on newer intels you cannot run coreboot anymore, there is public key embedded into the chipset that corresponds to the private one used for signing vendor bioses
07:42 imirkin: it's a lot like systemd... all the distributors seem to love it, adds a ton of questionable features and complexity, and makes common tasks 100x more difficult
07:44 LyndaT3: imirkin: I'll disagree with you on systemd. Big fan here. Makes complex dependency mgmt a breeze. Fully predictable. Extremely well documented. And responsive devs. What's not to like?
07:45 specing: fucking binary logs
07:45 imirkin: i like to be able to see logs, and i like to be able to kill processes
07:45 imirkin: anything that circumvents either of those qualifies as hard to use
07:47 LyndaT3: I've used it now for ~years. 'journalctl ...' is hardly diffucult. syslog's still available. different strokes ...
07:47 LyndaT3: grub2, otoh ...
07:48 LyndaT3: swiss-army-knife gone bad
07:48 imirkin: i've used 'less' for well over a decade. it works really well.
07:49 specing: less is more.
07:49 imirkin: certainly more than more :)
07:49 imirkin: which i *haven't* used in well over a decade
07:49 imirkin: [actually that's probably not true... every so often it comes up]
07:50 specing: more is not even installed anymore here
07:50 buhman:time for least
07:51 LyndaT3:would srsly like her grub menu back ...
07:51 specing: morst!
07:51 specing: LyndaT3: install coreboot, put kernel directly into bios flash
07:52 LyndaT3: many roads to the mountian. sticking with "all UEFI, all the time" on this one
07:55 imirkin: fwiw i recently got my first uefi system too... ended up using gummiboot
07:55 imirkin: very simple, but still lets you edit the cmdline
07:57 LyndaT3: imirkin: for good or bad, most distros are shipping with grub2 as default-install. need to get that figured out for general use. simpler 'workarounds' are certainly available. again, NOT a grub2 fan (really, what was the problem with grub1?)
07:58 imirkin: ok. i guess those distros also ship systemd, so i don't get far enough to worrying about what bootloader they use :)
08:02 LyndaT3: imirkin: I have a TRS-80 somewhere in storage I could sell ya ;-)
08:03 imirkin: i assume that only works with grub2? :p
08:03 LyndaT3: Show some respect!
08:06 specing: I still use the same grub1 that I installed 8 years ago
08:10 LyndaT3: specing: So do I , on *my* desktops. Can't deploy grub1 widely into production anymore as upstream refuses any/all support. And distros are following suit.
08:11 LyndaT3: Ironically, the same distros that are un-supporting grub-legacy don't know much about grub2's inner quirks.
08:11 specing: what support do you need lol?
08:12 specing: it reads HDDs for kernels and configs (APIs not going to change anytime soon) and loads a kernel
08:12 LyndaT3: specing: for grub2? try getting Xen Dom0 on UEFI+GRUB2 'happy' without talking to someone ...
08:12 LyndaT3: oh, for grub1? not much ... until something ELSE breaks, and the blame is place on grub
08:13 specing: why would it be placed on grub? It only loads the kernel
08:13 imirkin: dunno, i've never seen grub1 break
08:14 LyndaT3: imirkin: it's not grub1 that breaks ...
08:15 imirkin: so why blame it?
08:16 LyndaT3: talk to the distros. i don't.
08:17 imirkin: gentoo seems fine with whatever
08:22 LyndaT3: a commercial distro will not support their software if you insist on replacing their offerings with unsupported software. grub1 out of the box is no longer supported. add the patches needed to make for gpt compat, and you're even further from support. if you don't need/want that level of support, then use what you like. i certainly do.
08:23 imirkin: i don't need/want support
08:23 LyndaT3: then like i said.
08:23 imirkin: the reason i use linux is coz it makes it easy for me to do whatever i want
08:23 imirkin: using a commercial distro + support + etc removes a lot of that
08:24 LyndaT3: i'm done with this argument. use what you like. deploy what you like.
08:24 imirkin: we may also have different use-cases in mind ;) i mostly just run it on personal machines.
09:15 mlankhorst: imirkin: shrug, I can do whatever I want with ubuntu :P
09:15 mlankhorst: all the packaging's in git
09:15 mlankhorst: for the stuff I care about
09:16 imirkin_: mlankhorst: less /var/log/messages
09:16 imirkin_: can you do that?
09:16 imirkin_: [and not have it come back with "file not found"]
09:16 mlankhorst: naw
09:16 imirkin_: and then hit F to follow the file
09:16 mlankhorst: why?
09:17 imirkin_: coz that's something convenient to do when i'm waiting for e.g. network to come up
09:17 imirkin_: and i'm watching wtf dhcpcd is doing
09:17 mlankhorst: ah :p
09:17 imirkin_: btw, whoever invented "bad signal" for wifi... very unhappy with that person.
09:19 mlankhorst: I dont need a working network to get to the desktop though
09:20 mupuf: imirkin_: https://xkcd.com/1172/
09:20 imirkin_: or when journald is shitting its pans because someone logged an extra line into dmesg and one of its intermediate journal files is somehow corrupted and it goes into a 2-minute cpu hogging operation
09:20 imirkin_: and then you kill it because, you know, you've had enough
09:20 imirkin_: but don't worry -- systemd has got your back -- it just spawns it right back up!
09:21 imirkin_: mupuf: yes, ridiculous use-cases exist. i _really_ don't think mine is ridiculous
09:22 imirkin_: systemd breaks some _very_ basic system usability features for me
09:22 imirkin_: so any advantages it might bring are irrelevant
09:22 mupuf: if you want syslog, enable it
09:22 imirkin_: i don't want syslog. i want NOT journald.
09:22 imirkin_: is it possible to disable it?
09:22 mupuf: if you don;t want journald, tell it to use 0 MBit
09:22 imirkin_: coz i tried. really hard.
09:22 imirkin_: followed all the online guides
09:23 imirkin_: but sure enough, it would just spawn and spin cpu cycles for a few minutes
09:24 imirkin_: and in terms of simplicity, it's hard to improve on "append text to some file".
09:24 imirkin_: and simplicity is what you want with logging, not reliability
09:24 imirkin_: reliability implies complex logic, and that logic can go wrong
09:24 imirkin_: and when it goes wrong... you really want to be able to see the logs ;)
09:24 mupuf: Storage=none turns off all storage, all log data received will be dropped. Forwarding to other targets, such as the console, the kernel log buffer or a syslog daemon will still work however.
09:25 mupuf: the process will still run
09:25 mupuf: but it should not block ever again
09:25 mupuf: but then, you loose systemctl status
09:25 mupuf: and that sucks
09:26 imirkin_: it's all super intertwined
09:26 imirkin_: but it feels like the fight between me and lcd panel manufacturers -- i'm going to lose
09:26 mupuf: well, I love that systemd tracks processes
09:27 imirkin_: not enough buying power
09:27 mupuf: any other way is just a hack
09:27 mupuf: imirkin_: I know... I want my 16:10 back
09:27 mupuf: or even better, my 4:4
09:27 mupuf: 4:3
09:27 imirkin_: the buying power is from people who deploy thousands of machines in datacenters
09:27 imirkin_: and there something like systemd makes a *ton* of sense
09:28 mupuf: or the people buying glossy screens to watch movies
09:28 imirkin_: mupuf: yeah i meant 4:3.
09:28 mupuf: AKA, TV screens
09:28 imirkin_: i never got the glossy thing either. i hate it on tv screens too :)
09:28 mupuf: yeah, but even 16:10 is hard to find now...
09:28 mupuf: yep, those are super annoying
09:28 imirkin_: but you will never have as much buying power for whom laptops are dvd players
09:28 mupuf: thank the FSM, touchscreens fixed it!
09:29 mupuf: his mighty meatballs saved the day
09:30 imirkin_: but hopefully the individual use distros will stick around, like gentoo
09:31 imirkin_: and hopefully they'll be able to avoid adopting systemd as a required feature
09:31 imirkin_: (fully in favor of them allowing it to be used though...)
09:40 Karlton: linux from scratch guide + pacman package manager = my favourite distro :)
09:40 Karlton: though I still use gentoo to manage 32bit crap
09:42 cousin_luigi: Greetings.
09:44 cousin_luigi: I'm not sure if this is the right place to ask, but after switching to nouveau I can't use vdpau anymore. I have a "libvdpau_nouveau" package installed, but I wonder if I'm supposed to do anything more.
09:44 imirkin_: cousin_luigi: right place. you have a GTX 660, right?
09:45 cousin_luigi: imirkin_: correct
09:45 imirkin_: you need blob firmware to operate the video engines
09:45 imirkin_: see the guide at http://nouveau.freedesktop.org/wiki/VideoAcceleration/
09:46 imirkin_: (there's a script to extract it from the blob, but also this has been packaged up in a few distros)
09:46 cousin_luigi: imirkin_: thing is the error I see is "Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory"
09:46 imirkin_: mmmmm, that's odd
09:46 imirkin_: that means it's failing to load libvdpau_nouveau.so
09:47 imirkin_: env | grep VDPAU
09:47 cousin_luigi: nothing
09:47 imirkin_: excellent
09:47 imirkin_: pastebin the output of
09:47 imirkin_: strace -f -e open vdpauinfo
09:48 imirkin_: (pastebin the full output of that, including both stdout and stderr)
09:48 cousin_luigi: imirkin_: http://pastie.org/private/4euxy3lsusuklrxto5jc4w
09:49 imirkin_: wtf
09:49 imirkin_: humor me and pastebin your xorg log?
09:49 cousin_luigi: sorry, this is the complete one: http://pastie.org/private/mnfeqgz8fwpsijy0ervh0w
09:50 cousin_luigi: imirkin_: http://sprunge.us/beiM
09:51 imirkin_: [ 63.960] (II) NOUVEAU(0): [DRI2] VDPAU driver: nouveau
09:51 cousin_luigi: yes...
09:51 imirkin_: which is what i expected...
09:51 cousin_luigi: am I supposd to remove libvdpau1?
09:51 imirkin_: no
09:51 imirkin_: you need that...
09:52 imirkin_: give me a few
09:52 cousin_luigi: k, thanks
09:52 imirkin_: oh, in the meanwhile... is there a /usr/lib64/vdpau/libvdpau_nouveau.so.1 ?
09:53 cousin_luigi: imirkin_: yes
09:53 imirkin_: and what version of libvdpau do you have?
09:53 imirkin_: i think some _truly_ ancient ones only ever probed nvidia...
09:53 cousin_luigi: 0.8
09:53 cousin_luigi: does it qualify as ancient?
09:54 imirkin_: nope
09:54 imirkin_: but give me a few to rtfs
09:55 imirkin_: in the meanwhile, can you do VDPAU_DRIVER=nouveau vdpauinfo ?
09:56 cousin_luigi: imirkin_: http://pastie.org/private/2g5yxvaputhrvurufzpa
09:56 imirkin_: ok so that works...
09:56 imirkin_: you still need to install the firmware, otherwise you won't get any decoder caps
09:56 cousin_luigi: could this be an application problem?
09:57 imirkin_: (as indicated by the output)
09:57 cousin_luigi: ah
09:57 imirkin_: do you have multiple gpu's installed?
09:57 cousin_luigi: no, just that one
09:59 imirkin_: well it seems like somehow _vdp_get_driver_name_from_dri2 fails for you
09:59 imirkin_: i've never seen that before.
09:59 imirkin_: if you just stick the VDPAU_DRIVER=nouveau thing into your env, that should make it work
09:59 imirkin_: although that's a pretty dirty workaround... things should Just Work (tm)
10:00 mupuf: imirkin_: logind is pretty important
10:00 imirkin_: mupuf: for what?
10:00 mupuf: rootless-x
10:00 mupuf: or wayland
10:00 imirkin_: can't bring myself to care about either of those
10:00 mupuf: it does input management
10:01 imirkin_: but in any case, why does it have to be bundled with something that affects how i read my logs?
10:01 imirkin_: or how my processes start up?
10:01 mupuf: you don't care about apps listening to your inputs?
10:01 mupuf: well, it can possibly be reimplemented in a separate daemon
10:01 imirkin_: i've been just fine with X for quite a while
10:01 imirkin_: mupuf: unix philosophy is "do one thing, do it well"
10:02 mupuf:hates the root part
10:02 imirkin_: systemd goes full-speed against that
10:02 imirkin_: mupuf: how does X not being root avoid it from listening to your inputs?
10:02 mupuf: right, do service management well, like systemd does :D
10:02 mupuf: imirkin_: think about multiple x servers
10:03 imirkin_: mupuf: that never happens in practice.
10:03 mupuf: really?
10:03 mupuf: I do use this feature a lot when friends are over
10:03 imirkin_: i'm the only user of this comp
10:03 mupuf: the "invite" user is logged on
10:03 imirkin_: if i switch to a diff X server, only one can be active at a time
10:03 mupuf: and people have fun on this one
10:03 imirkin_: since they're on different vt's
10:03 mupuf: and not mess with my session
10:04 mupuf: yep, and vt's do not handle the input for you
10:04 imirkin_: unless i explicitly do -sharevts, and then yes, they both get the same inputs
10:04 imirkin_: however this scenario never happens.
10:04 imirkin_: in practice, friends just want an incognito window in chrome and that's it.
10:04 mupuf: VTs are going to disapear
10:05 mupuf: they do not belong in the kernel
10:05 imirkin_: meh. i semi-agree with that. esp in a post-kms world. but i dunno that we'll ever be in a post-kms world
10:06 imirkin_: but who knows. maybe efi will bring about vga's demise
10:06 mupuf: what's the link here?
10:07 imirkin_: think vga-only cards
10:07 imirkin_: text mode
10:07 mupuf: oh
10:07 mupuf: ahahah
10:07 mupuf: well, those computers may not even be able to boot a 4.0 kernel
10:07 imirkin_: or rather, cards that provide vga emulation and don't have an in-kernel driver
10:07 mupuf: not emough RAM :D
10:08 mupuf: well, you could have one kernel-based console
10:08 mupuf: or framebuffer
10:08 imirkin_: vesafb is *so slow* compared to vgacon
10:08 mupuf: no need to have all the complexity of the VTs
10:08 mupuf: ack
10:09 mupuf: I somehow do not even feel pity for the poor souls who need to have that
10:09 mupuf: I mean, get a RPi
10:09 mupuf: or something even cheaper
10:10 imirkin_: ... and insert it into your expensive hardware with a stupid gfx chip... how?
10:11 mupuf: just use the whole thing as a standalone computer
10:11 mupuf: and do not use this antique computer with an up to date kernel :)
10:11 mupuf: oh dear! I'm late
10:12 imirkin_: that's a very non-linux attitude
10:12 imirkin_: linux still boots on 486's
10:12 imirkin_: (386 support was dropped a while back due to various unpleasantness)
10:12 mupuf: right, but a TNT2 is also very old and still is not VGA text-only :)
10:12 imirkin_: it's not a question of age
10:13 mupuf: see you! TTYL
10:13 buhman: ooh
10:13 buhman: I remember my TNT(1)
10:13 imirkin_: you can get *brand new* cards without proper driver support
10:13 buhman: 8MB was a huge improvement over the previous video card
10:13 mupuf: imirkin_: vesa is not text-only
10:13 cousin_luigi: imirkin_: "Unknown PGRAPH archive order in this version." <- is this bad?
10:13 imirkin_: cousin_luigi: no, you don't need the pgraph firmware
10:14 imirkin_: the pgraph firmware is only extracted from 325.15
10:14 imirkin_: which is why the instructions tell you to get that
10:15 buhman: imirkin_++
10:15 buhman: journald sucks hard
10:17 cousin_luigi: imirkin_: oh
10:17 cousin_luigi: imirkin_: http://pastie.org/private/dsee17r4ghwrygabopxlig is it seeing it ?
10:18 imirkin_: yeah... note how decoder capabilities has stuff now
10:21 cousin_luigi: imirkin_: my system just crashed, hard
10:21 imirkin_: :(
10:21 cousin_luigi: while trying a player with vdpau
10:22 imirkin_: cousin_luigi: you're still on 3.16
10:22 imirkin_: you need 3.17
10:22 cousin_luigi: imirkin_: oh
10:22 imirkin_: or 3.19 would be even better
10:22 imirkin_: i'm guessing this is due to the same instability stuff you had been experiencing earlier
10:22 imirkin_: which i mentioned was most likely fixed in 3.17
10:23 cousin_luigi: well, the instability I noticed was on 3.11 actually. I wasn't sure about 3.16.
10:23 cousin_luigi: I'll have to change distro to have that:/
10:24 cousin_luigi: maybe fedora is not as bad as it looks:|
10:25 imirkin_: highly unlikely that you have to change distros just to use a new kernel
10:25 imirkin_: but do whatever works best for you
10:27 cousin_luigi: imirkin_: modules for various packages are built for the official kernel, I'd have to switch to dkms. I fear that would compromise the overall stability.
10:27 imirkin_: ok
10:27 imirkin_: you could ask your distro provider to cherry-pick that patch
10:28 cousin_luigi: imirkin_: it would take months to be accepted, I fear.
10:28 cousin_luigi: opensuse is like that
10:28 imirkin_: ah ok
10:34 cousin_luigi: imirkin_: well, thanks for everything. I guess I could install opensuse tumbleweed (3.19.2) and see what happens.
10:34 cousin_luigi: bbl
11:34 hakzsam: imirkin_, did you forget to review the series ? :)
11:35 imirkin_: i sure did!
11:35 imirkin_: ok, which patches do you want me to look at?
11:36 imirkin_: 6, 8, 9, 11, 13+?
11:36 hakzsam: give me a sec
11:36 hakzsam: http://lists.freedesktop.org/archives/mesa-dev/2015-March/080243.html
11:36 hakzsam: and 13, 14, 15
11:37 hakzsam: all patches prefixed by nvc0 actually
11:37 imirkin_: did you reply to the other guy?
11:37 hakzsam: no, I'll do
11:38 imirkin_: hm, so this will only be enabled for debug builds?
11:38 imirkin_: oh nm
11:38 hakzsam: ?
11:43 imirkin_: hakzsam: all good?
11:44 hakzsam: sounds good, thanks!
11:44 hakzsam: i'll make the fix
12:16 cousin_luigi: re
12:17 cousin_luigi: imirkin_: you still around?
12:17 imirkin_: always
12:17 cousin_luigi: imirkin_: :)
12:17 imirkin_: 24/7, in fact
12:17 cousin_luigi: imirkin_: I mean to package that firmware blob for suse and I have two questions.
12:18 cousin_luigi: imirkin_: should I use the version indicated in the guide and can I package that script if necessary?
12:18 imirkin_: package it as the blob file from nvidia + script to extract it
12:18 imirkin_: and then at install time, run the script
12:18 imirkin_: that way you're not distributing anything bad
12:18 cousin_luigi: bad?
12:18 imirkin_: well, blob license says you can't take it apart and redistribute the parts
12:19 cousin_luigi: http://www.nvidia.com/content/DriverDownload-March2009/licence.php?lang=us <- doesn't 2.1.2 allow for that?
12:19 imirkin_: "provided that the binary files thereof are not modified in any way (except for unzipping of compressed files)"
12:19 imirkin_: the script modifies the files considerably beyond that
12:20 cousin_luigi: ah, I thought it merely unpacked them
12:20 imirkin_: no, it goes diving in nv-kernel.o for the proper data
12:20 imirkin_: read the script :)
12:20 cousin_luigi: but at least I can give the user thhe .run? Or would it be better to make them download it?
12:21 imirkin_: yeah, you can put the .run + .py into the package
12:21 imirkin_: and on install, run the script on the user's local machine
12:21 imirkin_: note that ianal
12:21 cousin_luigi: I guess I'll also have to show the EULA
12:21 cousin_luigi: I wonder how fedorians do it
12:21 cousin_luigi: will try and see
12:22 imirkin_: for gentoo, it relies on -bindist and also on you having accepted the relevant nvidia license
12:22 penguser: nouveau sucks... I cannot boot up any ubuntu or debian with this crappy driver
12:22 cousin_luigi: imirkin_: wait, is that firmware also hardware-related?
12:22 imirkin_: penguser: yeah, it's the worst.
12:23 cousin_luigi: penguser: duh, don't use it then!
12:23 penguser: stop enabling it in distros.... so my OS can boot
12:23 imirkin_: penguser: we have no power over what distros do
12:23 penguser: I don't want to use it but it's installed by default
12:23 imirkin_: penguser: complain to your distro
12:23 penguser: they all do it
12:23 imirkin_: maybe it's not as horrid as you say it is then
12:24 imirkin_: or they're all just idiots
12:24 penguser: just because it's free
12:24 penguser: free crap
12:24 imirkin_: not sure what you're trying to achieve here
12:24 penguser: you don't support newer cards
12:25 imirkin_: are you trying to convince everyone here to shut the project down and go away? that's a long shot.
12:25 penguser: do you not test on new hardware?
12:25 imirkin_: if it's anything else, like what distros choose to do, we have no control over that, complain to the distros directly
12:25 cousin_luigi: penguser: man, you should probably use a mac
12:25 penguser: I have a cheap relatively modern 750
12:25 CptRageToaster: ooo drama!
12:26 penguser: but, when I boot up, the screen text is really small....fonts are unreadable...and it's blurry
12:26 imirkin_: penguser: that's great. of course given what you said earlier, i have absolutely no inclination to help you
12:26 penguser: it's because of crappy nouveau drivers
12:26 imirkin_: and i doubt anyone else does either
12:27 cousin_luigi: but does the desktop at least work properly?
12:27 CptRageToaster: penguser: You are in the wrong channel, sorry
12:29 imirkin_: next time you're looking for free support, reconsider your approach.
13:45 Karlton: penguser: How are you so sure it's a nouveau problem? What text are you looking at?
13:47 Karlton: for me it's the opposite, I get blurry console text if I don't load nouveau :)
14:19 imirkin_: skeggsb: i'm getting crashes in drmmode_fbcon_copy. i think the crash is in the fallback path's memset (the instruction is rep stos %rax,%es:(%rdi))
14:19 imirkin_: skeggsb: note that I'm running X like this: X -novtswitch -sharevts :1
14:30 imirkin_: skeggsb: btw, when reclocking on the GK208: nouveau E[ CLK][0000:01:00.0] failed to lower voltage: -22
14:30 imirkin_: skeggsb: let me know if you'd like additional info
15:22 imirkin_: oh fun. all the texturegradoffset stuff is broken on gk110
15:22 imirkin_: somehow i never noticed =/
15:22 imirkin_: they probably put the offset params somewhere funny...
15:48 imirkin_: ... and a bunch of ARB_gs5 stuff fails too. ugh.
15:48 imirkin_: for no apparent reason :(
15:49 imirkin_: i'm gonna blame gbm on this one...
15:50 imirkin_: yeah, passes with X
19:56 whompy: Ha, fun fact: the bisection of the Portal crash ended on the only nouveau commit with my Tested-By. Fail.
20:02 penguser: Karlton, didn't know I was still logged on...sorry :)
20:03 penguser: Karlton, I know it's a nouveau driver problem because I managed to install a nvidia driver - although it was almost impossible and it would have fixed the screen problem
20:15 Karlton: penguser: Okay, I just wanted to make sure, not sure why nouveau makes fonts look different for you.
20:18 penguser: it was the same on several distros and DEs
20:18 penguser: text was so tiny and blurry...
20:19 penguser: I tried vga=771 and nomodeset but didn't make a difference
20:19 imirkin: nomodeset fully disables nouveau, so unlikely that your issue was with nouveau
20:21 penguser: maybe the commands didn't take?
20:22 imirkin: you also mentioned that you had a GTX 750, which is a GM107. Until fairly recent kernels, there was never any support for it at all, so unless you were trying a distro with a very up-to-date kernel, chances are nouveau would just ignore the card entirely
20:31 Karlton: penguser: Yeah it may have not even loaded if you didn't check using dmesg | grep nouveau
20:33 Karlton: the default framebuffer provided by the kernel never gets my screen resolution correct until nouveau loads
20:50 fling: Is not nouveau loading any firmwares for nv92? https://bpaste.net/show/ad3dabc04a77
20:53 imirkin: fling: only for vdpau decoding (which, iirc, is somehow very broken on G92's)
20:53 fling: imirkin: how to disable it?
20:53 imirkin: disable what?
20:53 fling: firmware loading for it?
20:53 fling: or is not it loading anything if I don't have firmwares installed?
20:54 imirkin: you could just remove libvdpau_nouveau.so
20:54 imirkin: if you don't have the firmware, it certainly can't be loaded
20:54 fling: And it does not have a blob in kernel for this?
20:55 imirkin: the only "blobs" in the kernel are ones written by nouveau devs (but pre-compiled for convenience). however those are only used in later gpu generations.
20:55 fling: imirkin: thanks for the info.