04:25SpComb: if I have an ancient 7800GT, connected via DVI-HDMI to a monitor with a native 4k resolution, and I'm trying to use this as a fb-console to debug boot-time issues (not running X or anything), is this configuration supposed to work? Current behaviour is horrible corruption on the display (each horizontal line is offset by some random amount)
04:26SpComb: or should I just use the boot video= parameter to set some more smaller resolution and be happy
04:46glennk: SpComb, you need a 6xx series or newer card for the hardware to support 4k
04:47SpComb: yeah, I don't need or want 4k output, I just want something that's not corrupted :)
04:47SpComb: but nouveau doesn't seem to behave sanely by default there
07:35hakzsam: does someone have a NVD7 and/or a NVC3? I would need to trace the blob
07:48imirkin: SpComb: odd, we should be ignoring modes that are too high bandwidth...
07:48imirkin: SpComb: can you pastebin the output of grep . /sys/class/dri/card*-*/modes
07:49imirkin: mlankhorst: you have a nvd7 right?
07:53imirkin: SpComb: er, drm, not dri =/
07:54RSpliet: imirkin: are we? do we know the bandwidth requirements of a mode? the bandwidth provided by a performance level to the scanout logic?
07:55RSpliet: or are you only referring to the range of the PLLs?
07:56RSpliet: pmoreau: have you gotten round testing my tree?
07:56imirkin: RSpliet: i'm referring to max pixel clocks
07:56imirkin: e.g. if you have a 135mhz pixel clock
07:56imirkin: that's not enough for 4k :)
07:57RSpliet: nope, that barely does it for 1080p :p
07:57imirkin: iirc 7800GT had dual-link DVI though
07:57imirkin: but perhaps HDMI doesn't support that? dunno
07:57imirkin: afaik hdmi does do 2560x1600, and you def need dual-link for that
07:58imirkin: but perhaps that's some revision of hdmi? dunno.
07:59RSpliet: there are several revisions of HDMI to increase bandwidth requirements
08:00RSpliet: ouch btw... 3840x2160 needs a 712.75MHz pixel clock
08:00imirkin: and how do those revisions map onto dvi?
08:01imirkin: and esp dual-link dvi
08:01glennk: RSpliet, at 24Hz?
08:01RSpliet: gkennk: no, that's 60Hz... don't think Kepler can do that :-D
08:02RSpliet: imirkin: no idea... I just follow the HDMI wikipedia page
08:02RSpliet: which prescribes a 600MHz pixel clock for HDMI 2.0
08:02glennk: hdmi 4k is 24 or 30Hz, unless you have hdmi 2.0
08:02imirkin: afaik hdmi 2.0 isn't a thing yet
08:03imirkin: on either side of the cable
08:03RSpliet: it is, since September 4, 2013
08:03imirkin: RSpliet: on paper maybe
08:03imirkin: aka "not a thing"
08:03imirkin: there are no sources, and there are no sinks
08:06RSpliet: GeForce GTX980 does HDMI 2.0
08:07glennk: 1.4 cards can do chroma subsampled 4k@60
08:07imirkin: hah, ok
08:07imirkin: so it's a thing now. yay!
08:08RSpliet: I like things
08:08imirkin: and afaik the next gen radeons will have it too
08:40Yoshimo: 980 is a nice beast
08:41RSpliet: yeah, a hippo!
09:22SpComb: imirkin: https://gist.github.com/SpComb/fbde991cb7a6a44ac27c it seems to go for the 3840x2160 mode, and to monitor picks it up as 1920x2160@30; with a debian wheezy 3.2 kernel
09:24imirkin: well, booting with video=1920x1080 should fix the glitch
09:24imirkin: but we should be filtering that mode out... no amount of dvi can support 3840x2160
09:25imirkin: (at least not over a single connector)
09:26imirkin: probably hitting some funkiness in the code as it was written well before 4k was a thing
09:29RSpliet: imirkin: sounds like a job to take on in the ->atomic modesetting conversion
09:32SpComb: I just reverted to vesafb, but it was certainly surprising at first when this normally-headless box booted into some initramfs/fsck prompt and the only monitor I had at hand was a 4k one :)
09:33RSpliet: first world problems! :-P
09:36mlankhorst: first world problems are still problems..
09:39imirkin: RSpliet: i think dispnv04 is going to get left below
09:51glennk: imirkin, single link can do it - at 17Hz...
09:52imirkin: glennk: not one of the available resolutions in the edid i'm sure
09:52imirkin: er, modes. wtvr. you know what i mean.
11:29RSpliet: imirkin: any reason why dispnv04 will be left out?
11:29RSpliet: or just time and resources...
11:30imirkin: RSpliet: i think we know a lot less about modesetting on those, and implementing atomic may not even really be possible
11:31imirkin: RSpliet: ... and time and resources :)
11:31imirkin: i know i'm not doing it. and afaik skeggsb_ has said that dispnv04 is in life support mode as far as he's concerned
11:31imirkin: i did add overlays a while back, but that was pretty minor and separate from the rest of it
11:42nightfuri: would games(with wine) using minimal graphics work when using nouveau ?
11:43imirkin: what GPU do you have?
11:43nightfuri: nvidia geforce 210.
11:44imirkin: yeah should be fine
11:44imirkin: with kernel 3.19 you should be able to reclock it too
11:44nightfuri: i am on 4.0
11:44imirkin: boot with nouveau.pstate=1 and you should be able to do that...
11:45nightfuri: and i dont know about reclocking. is it necessary ?
11:45imirkin: but your card probably has multiple perf levels
11:45imirkin: and if you want to switch between them, you need reclocking
11:46imirkin: not sure how 'minimal' the graphics you're looking for are
11:46imirkin: if it's gaming, chances are you'll want the higher clocks
11:46imirkin: if it's gnome-shell, whatever the default is will be fine
11:47nightfuri: well the problem is am trying to load game i just hear the bgm and the screen is black with just bits of pixels here and there. and i get this error from terminal libGL error: image driver extension not found
11:47nightfuri: libGL error: failed to load driver: nouveau
11:47imirkin: pastebin dmesg and glxinfo output
11:50nightfuri: dmesg output- http://dpaste.com/1ZZC0TP
11:50nightfuri: Graphics: Card NVIDIA GT218 [GeForce 210] bus-ID 01:00.0
11:50nightfuri: Display Server X.Org 1.15.1 drivers nouveau (unloaded: fbdev,vesa) Resolution email@example.com
11:50nightfuri: GLX Renderer Gallium 0.4 on NVA8 GLX Version 3.0 Mesa 10.1.3 Direct Rendering Yes
11:50imirkin: well that all seems fine... pretty old X, but that's no problem... pretty old mesa too, but should work
11:51imirkin: sounds like you might be running a 32-bit game but don't have a 32-bit mesa installed maybe?
11:51nightfuri: yes 32-bit game it is running in 32bit wine.
11:53nightfuri: how do i get that 32-bit mesa thing ?
11:54imirkin: check with your distro support?
11:55buhman: wow, 1366x768
11:55buhman: such 2003
11:56nightfuri: sure. could you tell me the 32bit mesa package name ? i find lot things with the name mesa attached to it ?
11:56imirkin: buhman: but he has working accel, unlike you :p
11:56imirkin: nightfuri: depends on the distro.. in gentoo, just enable the abi_x86_32 flag, and all good :)
11:56imirkin: for other distros, talk to people who aren't me
11:57buhman: time for imirkinOS
11:57imirkin: when gentoo switches to systemd, yes
11:57nightfuri: imirkin: ahah i am kind of novice. but thank you for your advice :)
11:57buhman: imirkin: I would be interested in a not-shit journald
11:58nightfuri: i ll look into it
11:58imirkin: buhman: aka "syslogd"?
11:58nightfuri: buhman: whats wow about it ? is it too old ?
11:58buhman: imirkin: well, the binary log searching/sorting that journald can do is nice
11:59buhman: the idea is great; the implementation is absolutely terrible
12:00buhman: it shouldn't take 2 minutes grab the last 10 lines of a log, regardless of log size
12:00buhman: that seek should basically be O(1)
12:01imirkin: buhman: aka "tail /var/log/messages"? yeah, that's nice.
12:01buhman: I don't like the syslog facility -> file mapping nonsense
12:01imirkin: so don't use it
12:01buhman: and hardly ever useful
12:01buhman: syslog can't say 'journalctl -u foo.service'
12:02imirkin: what does that do?
12:02imirkin: is that the same as "grep sshd /var/log/messages"?
12:02imirkin: [or whatever]
12:10Karlton: buhman: I never really had a GNU install without grep, so is that really necessary?
12:15rardiol: My fan went off and didn't turn back on, overheating the computer. Nouveau shows nothing interesting in the logs except for the messages for achieving fanboost, downclock and critical temperature.
12:16imirkin: rardiol: what gpu?
12:16rardiol: 01:00.0 VGA compatible controller: NVIDIA Corporation GT218M [GeForce 310M] (rev a2)
12:17rardiol: imirkin: 01:00.0 VGA compatible controller: NVIDIA Corporation GT218M [GeForce 310M] (rev a2)
12:17imirkin: hm. laptops tend not to have separate fans
12:18rardiol: Yeah, I'm actually not sure if this is nouveau's problem. I just assumed because of the fanboost message
12:19rardiol: Maybe it's the CPU fan?
12:19imirkin: nouveau doesn't necessarily realize there's no gpu fan
12:19imirkin: and it has various logic to try to spin up the fan
12:19imirkin: when it notices the temp goes up
12:23nightfuri: any ubuntu/mint users ?
12:23rardiol: I tried playing around with temp1_auto_point1_temp and it seems fanboost doesn't actually matters. So it's not nouveau's fan? Where is the problem them? the kernel?
12:44nightfuri: imirkin:hello itseems i have got libglapi-mesa:i386 installed already
12:44imirkin: nightfuri: i have no idea what that is, but i doubt it's what you need
12:44imirkin: glapi is an old thing as is no longer exposed by mesa
12:45imirkin: (although you have a pretty old version of mesa, perahps it was still a thing back then)
12:45imirkin: you need a 32-bit nouveau_dri.so
12:45imirkin: however you get that is fine by me.
12:46nightfuri: it says "The Mesa GL API module is responsible for dispatching all the gl* functions. It is intended to be mainly used by both the libgles1-mesa and libgles2-mesa packages."
12:47imirkin: no matter how much you might want, i'm not going to look at how ubuntu or whatever distro packaging is done.
12:47imirkin: get help from the relevant support channel
12:47nightfuri: imirkin: np thats ok
12:48nightfuri: but what exactly do i need to get ?
12:48nightfuri: a 32 bit mesa or 32bit nouveau driver ?
12:50nightfuri: thank you
12:50imirkin: there is no such thing as "nouveau driver"
12:50imirkin: nouveau is a collection of several components
12:50imirkin: one of which is mesa
13:05nightfuri: imirkin: i think i have nouveau_dri.so /usr/lib/i386-linux-gnu/dri/nouveau_dri.so /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
13:06imirkin: cool, so you should be good then
13:06nightfuri: but i had it before the error too ?
13:08imirkin: oh weird
13:08imirkin: do you happen to have a 'glxinfo32'?
13:10nightfuri: i have just glxinfo. dont know about glxinfo32
13:11imirkin: sometimes there's a 32-bit version of glxinfo
13:11imirkin: helps debug annoying 32-bit issues
13:11nightfuri: ah ah
13:11imirkin: can you double-check that running 'glxgears' works fine?
13:13nightfuri: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" but the gears are working fine as what i can see
13:13nightfuri: by the way wont the glxinfo and glxinfo32 wont conflict if i have both ?
13:13imirkin: not if one's called glxinfo and one's called glxinfo32 :)
13:16nightfuri: glxinfo32 could be the reason for the libgl error from a 32bit program ?
13:17imirkin: but it could help debug the issue.
13:32nightfuri: just running glxinfo i get this error starting- glxinfo name of display: :0 libGL error: image driver extension not found libGL error: failed to load driver: nouveau
13:32imirkin: nightfuri: oh. that's "good" (so to speak)
13:32imirkin: can you pastebin the output of LIBGL_DEBUG=verbose glxinfo ?
13:34nightfuri: imirkin: http://dpaste.com/0J521CB
13:35imirkin: looks like it still loads fine
13:35imirkin: so that's fine
13:35imirkin: perhaps your 32-bit thing is fine too -- what's the issue there?
13:35nightfuri: same -libGL error: image driver extension not found libGL error: failed to load driver: nouveau
13:36nightfuri: get that when running it.
13:36imirkin: well presumably you're not too concerned about getting those messages
13:36imirkin: and you instead have some other sort of issue
13:36nightfuri: about the gui. only just few pixels scattered are visible. rest is black screen.
13:37nightfuri: yes not concerned. but thats for the terminal part so that i can be giving relevant info i thought
13:38imirkin: well, the first suggestion i have is to update mesa
13:38imirkin: a lot of issues have been fixed...
13:39nightfuri: GLX Renderer: Gallium 0.4 on NVA8 GLX Version: 3.0 Mesa 10.1.3 Direct Rendering: Yes
13:39nightfuri: update to what version mesa ?
13:39imirkin: 10.5.3 is latest released
13:44a1fa: imirkin: i got it working today
13:44imirkin: a1fa: congrats :)
13:44a1fa: imirkin:i had to reinstall mesa driver
13:45a1fa: for some reason, unrelated to anything, i got two wierd stripes down the monitor
13:45a1fa: it only shows up in X with either driver
13:45a1fa: BIOS, and framebuffer no issues
13:46a1fa: wonder if it has anything to do with the firmware and if it got reloaded by the new nvidia driver
13:46imirkin: unlikely, the firmware is only used for decoding videos
13:47a1fa: odd. i have two of the same monitors, so will replace the monitor
13:47a1fa: and the cable to see if it is the monitor doing it
13:47a1fa: but all good.. i am able to decode 1080p youtube video
13:47a1fa: with slight tearing
13:48a1fa: 720p smooth as butter
13:48a1fa: only issue is, atom 230 cant get out of its own way
13:48nightfuri: where to get the latest mesa from ?
13:48a1fa: from 15.04
13:49nightfuri: oh you are ubuntu ? whats the package name ?
13:49a1fa: mesa-video-dri or something
13:51a1fa: want me to look it up?
13:51imirkin: a1fa: increase clock speeds for 1080p decode maybe?
13:51imirkin: a1fa: boot with nouveau.pstate=1
13:51imirkin: and then you can switch to higher pstates
13:52a1fa: i'll do that
13:52a1fa: i can put that into grub, right?
13:53a1fa: nouveau > nvidia driver at this point, at least for this platform
13:53nightfuri: Mesa VDPAU video acceleration drivers ? is this what mesa is called ?
13:53mlankhorst: might be able to look for pstate in /sys, chmod it to u+w and then cat into it..
13:54nightfuri: imirkin: i think i got Mesa VDPAU video acceleration drivers 10.6.0 available to download.
13:57imirkin: a1fa: yes
13:57imirkin: mlankhorst: pretty sure that won't actually ehlp
13:59mlankhorst: imirkin: it would. :P
14:00imirkin: mlankhorst: doesn't nouveau also use it to figure out whether it should actually do things in response to writes to that file?
14:00imirkin: mlankhorst: also don't you have to have that option for that file to appear?
14:01mlankhorst: hm I think it exists
14:01imirkin: not without pstate=1
14:01mlankhorst: oh right
14:02mlankhorst: it changed in the last few kernels or something
14:02nightfuri: a1fa: whats the version you got ?
14:02imirkin: yeah, someone complained about the file being in sysfs
14:02imirkin: too convenient, apparently
14:02mlankhorst: it was useful there
14:03a1fa: not sure i can look it up
14:03a1fa: there are other ppas with latest mesa with latest llvm
14:03nightfuri: i got xedgers ppa
14:04a1fa: yep thats the one
14:05nightfuri: was it mesa-vdpau-drivers 10.6.0 ?
14:06a1fa: twant me to check need to run into arage
14:08nightfuri: if you dont mind and if you get free let me know about it :)
14:08a1fa: tone sec.. need to pvp someone in a game ;)
14:09nightfuri: haha. what game is that ?
14:09a1fa: 7days to die
14:18a1fa: ok going there
14:18a1fa: guy is hiding in a house somewhere... a troll
14:18a1fa: actually see if i can ssh to it
14:19a1fa: Version: 10.5.2-0ubuntu1
14:20a1fa: now to figure out which file to modify for grub
14:23a1fa: huh things have changed
14:23a1fa: have no ide which file to modify
15:10Karlton: a1fa: /boot/grub/grub.cfg ?
15:29imirkin: SpComb: btw, happened to notice this while going through and closing tabs... you're using kernel 3.2.0 -- a *ton* of fixes have gone in since then, i wouldn't be surprised if the resolution limiting was one of them
15:51SpComb: imirkin: quite possible
15:58imirkin: 3.2 is over 3 years old now
15:58buhman: might as well be kernel 2.4
15:58imirkin: which is like a millenia in terms of graphics driver development
15:59imirkin: well, kernel 2.6.0 came out in like 2001 or so
15:59buhman: except for gk106
21:08gnurou: imirkin: re TX1: we have some basic rendering stuff running (on top of libdrm), but still not using Mesa. Right now we are still concentrating on secure boot issues, and I hope this will solve the deadlock for dGPU as well
21:42pmoreau: RSpliet: No… Unfortunately I had no time to get back to it… (And was secretely hoping you would have time to fix the compilation error ;) )