01:30 mupuf: imirkin: 168548 sample points for the fan
01:30 mupuf: automation is great, isn't it?
01:30 imirkin_: :)
01:31 mupuf: Summary: 168548 results, 149865 pass (88.92%), 18683 fail (11.1%)
01:31 mupuf: that's when I allow an off by one
01:32 mupuf: but anyway, will work on that a little more before sending the email to nvidia
01:33 mupuf: and I will make a safe model, that will make the fan louder than we could, but not as loud as currently
04:01 Aristar: "Nouveau openGL drivers don't support multithreaded rendering" <--is tihs still true? I just saw this when trying out the latest qupzilla browser
04:08 Aristar: or maybe older kernel/userspace? hrrm
04:08 airlied: no I think it's still accurate
04:08 Aristar: fairly recent here though really old gpu
04:08 Aristar: Kernel 4.13.10, X11 1.19.5, OpenGL 3.3, Mesa 17.2.4 (compat-v: 3.0), GPU: NV86 (G86M)
04:09 Aristar: yeah i guess it makes sense, most webkit browsers have issues
04:09 Aristar: "Nouveau openGL driver detected. Qt WebEngine will disable usage of the GPU."
04:09 Aristar: lol
04:09 Aristar: not that i need it for this one anyhow
04:19 imirkin: Aristar: it's still true.
04:19 imirkin: Aristar: qt does stuff which kills nouveau.
04:20 Aristar: gnome seems to as well lately
04:20 Aristar: once in awihle i get curious how bad gnome is and i give it a try
04:21 Aristar: even on fedora where i believe the most gnome devs are
04:22 imirkin: very few, if any, games used to do this
04:23 imirkin: and then all of a sudden the desktop guys came in and said "yeah, let's just use the GL drivers without worrying about whether they're ready for the totally different usage"
04:23 Aristar: heh
04:23 imirkin: otoh i've probably spent more time complaining about it than it would have taken me to fix it
04:24 imirkin: but someone else has kinda acquired the lock on that project
04:24 skeggsb: mutex_unlock(&glthreads.mutex)
04:24 imirkin: hehe
04:24 imirkin: skeggsb: i think you forgot "git push current-branch"
04:25 imirkin: skeggsb: that said, i think the proper move is to just rewrite everything from scratch
04:25 imirkin: even if it's not required, it should be a lot more fun
04:28 airlied: yeah first line of code in a new driver, pthread_mutex_t driver lock;
04:28 Aristar: didn't gnome try thta but ended up reusing lots of code with the same unfixed longstanding bugs?
04:28 airlied: skeggsb: where did you get to before you got vmmed?
04:28 Aristar: i mean heck i feel bad for MATE maintainers/developers
04:31 imirkin: Aristar: dunno. i've had to switch away from gdm now that it uses gnome-shell though.
04:31 imirkin: very sad.
04:32 Aristar: "You're using gnome-screensaver? Do you want ants? Because that's how you get ants."
04:32 Aristar: </meme>
04:34 Aristar: ...wtf i have 4GB of logs
04:34 imirkin: airlied: well, ideally in a way that doesn't cause the driver do do mutex_lock(); sleep(); mutex_unlock()...
04:36 imirkin: either way, part of the solution is to move libdrm_nouveau into the nouveau driver - it needs more control.
04:37 imirkin: all of which probably means a break from nv30
09:58 jolar2: imirkin: Ok, so I have fixed the kernel crashes/oopsing. Is there any way I can force hotplug without your DDX fixes?
09:58 jolar2: imirkin: or rather, force detection of the docking connectors
11:01 jolar2: I added NULL pointer checks in nv50_mstm_register_connector so we do not call drm_fb_helper_add_one_connector if !drm->fbcon
11:01 jolar2: (and the same check in nv50_mstm_destroy_connector)
11:43 pmoreau: imirkin: I didn’t went with “val = -imm->reg.data.s32” for fear of some implicit casting going on that would ruin it.
11:43 pmoreau: But I agree with getting rid of OP_SUB altogether.
12:55 jolar2: Does this look reasonable? https://bugs.freedesktop.org/page.cgi?id=splinter.html&bug=101778&attachment=135298
13:43 jolar2: Another question: What part of nouveau should guarantee that drm->fbcon is assigned when register_connector is invoked?
13:45 karolherbst: jolar2: you should see it in the code
13:47 jolar2: karolherbst: Ok, well, wherever it is, I suspect it has not run as it should because of the NULL pointer dereference.
13:49 karolherbst: depends
13:49 jolar2: karolherbst: could you test my patch and see if it ruins MST for you?
13:49 jolar2: with the P50
13:49 karolherbst: jolar2: fix I wrote some days ago: https://github.com/skeggsb/nouveau/commit/330db527f14c9893d96d8b647b4153b97d9a88d6
13:50 jolar2: karolherbst: I'll grab it as well
13:50 karolherbst: it won't help you
13:51 jolar2: probably not
13:51 karolherbst: just wanted to show, that I fixed an issue where fbcon->helper.fb was NULL
13:52 jolar2: karolherbst: thanks
13:52 karolherbst: but it is odd that fbcon was NULL
13:52 karolherbst: ... mhhh
13:53 karolherbst: it shouldn't be afaik
13:54 jolar2: karolherbst: no definitely not
13:55 jolar2: karolherbst: since there is no point in accessing fbcon->helper if fbcon points at NULL
13:55 karolherbst: you should figure out why fbcon is NULL
13:55 jolar2: exactly...
13:55 jolar2: and why it isn't in your P50 case...
13:56 jolar2: (or else you would have gotten the oops as well)
13:57 jolar2: my current guess is that nouveau_fbcon_create should assign it
13:57 karolherbst: no, a fbcon = should do it
13:57 jolar2: ?
13:57 jolar2: oh
13:58 karolherbst: in nouveau_fbcon_init
13:58 karolherbst: you see, there is no way it can be NULL
13:58 karolherbst: not really
13:58 karolherbst: except there is a reason :)
13:59 jolar2: in nouveau_fbcon_init it assigned to drm->fbcon
13:59 jolar2: which is NULL
13:59 karolherbst: read the function again
13:59 jolar2: shit
13:59 jolar2: wrong _init-function
13:59 jolar2: that was accel_init
14:00 karolherbst: can you get me your lspci line of the nvida GPU?
14:00 karolherbst: it doesn't say 3d accelerator, does it?
14:01 jolar2: 01:00.0 3D controller: NVIDIA Corporation GM107GLM [Quadro M1200 Mobile] (rev a2)
14:01 karolherbst: .......
14:01 karolherbst: the fuck
14:01 karolherbst: the actual fuck
14:01 karolherbst: jolar2: https://github.com/karolherbst/nouveau/blob/master/drm/nouveau/nouveau_fbcon.c#L503
14:01 karolherbst: now guess what ;)
14:02 karolherbst: like I already knew that would be the case...
14:02 karolherbst: usually it says "VGA compatible controller"
14:02 karolherbst: and 3d controller means: no display
14:02 karolherbst: but there we are
14:03 jolar2: oh...
14:03 karolherbst: now you only have to hope that dev->mode_config.num_crtc isn't 0 either
14:03 karolherbst: you can check with a printk
14:03 karolherbst: and you should remove that PCI_CLASS_DISPLAY_VGA line there
14:03 karolherbst: because we can't trust it
14:03 jolar2: you mean your P50 shows something different in lspci?
14:03 karolherbst: yeah
14:04 jolar2: well, just one thing though... HDMI does work with nouveau without docking
14:04 imirkin: jolar2: just restart X and it should pick up the new connectors
14:04 jolar2: are you sure this is MST specific?
14:04 karolherbst: imirkin: no, it is a nouveau bug
14:04 imirkin: karolherbst: nah, 3d controller can have displays
14:04 karolherbst: an actual bug inside the kernel
14:04 karolherbst: not according to that code
14:04 imirkin: karolherbst: it's just frequent that 3d controllers don't have displays
14:05 karolherbst: yeah, the code is still wrong
14:05 karolherbst: I am sure it will work if that check is removed
14:05 imirkin: (dev->pdev->class >> 8) != PCI_CLASS_DISPLAY_VGA
14:05 jolar2: I'll try it and rebuild nouveau
14:05 jolar2: hold on
14:05 imirkin: that should still work iirc
14:05 imirkin: 3d controller is 0301
14:05 karolherbst: well, drm->fbcon is assigned later
14:05 karolherbst: mhh
14:06 karolherbst: then num_crtc is 0?
14:06 imirkin: that would mean the DCB is empty
14:06 karolherbst: jolar2: did you send us your vbios?
14:06 karolherbst: ohh wait, you did
14:06 jolar2: can a parallel thread change the values of num_crtc?
14:06 karolherbst: I just don
14:06 imirkin: oh hm, i lied
14:06 imirkin: include/linux/pci_ids.h:#define PCI_CLASS_DISPLAY_VGA 0x0300
14:06 karolherbst: :)
14:07 jolar2: ok let's try that line first
14:07 jolar2: hold on
14:07 karolherbst: I think it should be >> 16 and check against that constant above that
14:07 karolherbst: there is a group one
14:07 karolherbst: but the name is a bit odd?
14:08 karolherbst: PCI_BASE_CLASS_DISPLAY, right
14:09 karolherbst: and 3d controller is 0302
14:09 jolar2: removing the line does not fix the problem
14:09 jolar2: so maybe num_crtc is indeed 0
14:09 karolherbst: jolar2: can you give me your vbios again?
14:09 jolar2: karolherbst: sure
14:09 jolar2: karolherbst: where would I upload it?
14:10 karolherbst: somewhere
14:10 jolar2: lol
14:10 jolar2: oj
14:10 jolar2: ok
14:11 jolar2: regular cp operation from /sys/kernel/debug/dri/1/vbios.rom fine?
14:11 karolherbst: not quite sure
14:11 karolherbst: I know that cat works
14:12 jolar2: I'll try a send over IRC
14:12 karolherbst: good luck
14:14 jolar2: karolherbst: got it?
14:14 karolherbst: wow, it works
14:14 jolar2: <3 irssi
14:15 karolherbst: imirkin: well, DCB has 6 valid entries
14:16 karolherbst: jolar2: can you put a printk?
14:16 karolherbst: just to double check?
14:17 jolar2: karolherbst: sure, but then I would have to reboot... is it not possible to do nvkm_debug?
14:17 jolar2: but then I would need access to something called "subdev"
14:18 karolherbst: jolar2: dmesg | grep DCB
14:18 karolherbst: you should get some lines, right?
14:19 karolherbst: and are you sure you removed the correct line and recompiled/installed everything correctly?
14:21 jolar2: karolherbst: nope no lines
14:21 karolherbst: ...
14:21 karolherbst: either your dmesg is short or something complety messy is going on
14:21 karolherbst: can you give me your entire dmesg?
14:21 jolar2: is it possible to access "subdev" in nouveau_fbcon.c?
14:22 karolherbst: no
14:22 karolherbst: just use printk
14:22 jolar2: but then I would have to reboot I guess?
14:22 jolar2: i only have nouveau.debug and drm.debug set
14:22 karolherbst: yeah well, your dmesg is full
14:23 karolherbst: jolar2: what do you mena by reboot?
14:23 karolherbst: you have to reload nouveau
14:23 karolherbst: no matter how
14:23 jolar2: that is no problem
14:23 jolar2: I thought I had to change kernel debug level
14:23 jolar2: for printk
14:23 karolherbst: no
14:23 jolar2: ok
14:23 karolherbst: just use KERN_WARNING or so
14:23 karolherbst: or KERN_ERR or whatever
14:23 jolar2: okidoki
14:31 jolar2: hmmm
14:31 jolar2: still no output from printk
14:31 jolar2: funny thing though, I actually got the display to show up in xrandr this time
14:32 jolar2: enabling it threw me into gdm login screen though...
14:32 jolar2: printk(KERN_WARNING "num_crtc: %i\n", dev->mode_config.num_crtc);
14:32 jolar2: karolherbst: anything wrong with his?
14:33 karolherbst: do you see anything related to nouveua in dmesg?
14:33 karolherbst: maybe you should disable that drm debugging
14:34 jolar2: yeah
14:34 jolar2: guess I have to reboot
14:34 jolar2: wow... I actually managed to enable the external screen!
14:34 jolar2: let's connect the other one
14:35 jolar2: yup
14:35 jolar2: works fine
14:35 jolar2: sweet
14:35 karolherbst: :)
14:35 jolar2: maybe that line did do it
14:35 karolherbst: well, which one else?
14:35 jolar2: well, printk is not probable...
14:35 karolherbst: ;)
14:35 jolar2: unless delays etc matter
14:36 karolherbst: no
14:36 jolar2: well, then I would like to extend a pre-emptive thank you
14:36 imirkin: karolherbst: there was a time, long long ago, when the class was an inidication of display-or-no-display.
14:36 karolherbst: you can write a proper patch and send it to the ML
14:36 jolar2: just gotta test this some more
14:36 imirkin: karolherbst: that time has long-ago ended however
14:36 imirkin: now it's just an indication of "primary" vs "secondary" gpu
14:36 jolar2: karolherbst: sure, should we keep the NULL checks? (I was inspired by the intel mst code)
14:36 karolherbst: imirkin: well, it isn't the first time people don't care shit about keeping things sane
14:37 karolherbst: imirkin: well, not even that
14:37 imirkin: indication, not guarantee :)
14:37 karolherbst: for me 3d controller == VGA
14:37 karolherbst: it makes no differenc whatsoever
14:37 karolherbst: you still need the same code for both, don't you?
14:38 karolherbst: jolar2: no
14:38 imirkin: need to double-check with skeggsb ... it's *possible* that there was some headless Tesla high-end GPU without a display block but with a DCB that indicated heads.
14:38 karolherbst: imirkin: well, we can do so on the ML
14:38 imirkin: a long time ago
14:39 imirkin: in a land far far away (aka australia)
14:40 karolherbst: imirkin: https://github.com/karolherbst/nouveau/commit/0a2b44780
14:40 jolar2: karolherbst: why not? for performance?
14:40 karolherbst: jolar2: no, because it shouldn't be NULL at all
14:40 karolherbst: you can keep the ifs, but the there should be BUG() thingies
14:40 jolar2: karolherbst: gotcha
14:41 karolherbst: what was the evil one, BUG or BUG_ON?
14:41 karolherbst: don't remember
14:41 jolar2: I'll find out through the internet or something
14:41 jolar2: I wanna try a reboot now without all dmesg crap
14:41 jolar2: brb
14:41 karolherbst: and the BUG message should indicate that something is screwed
14:41 imirkin: karolherbst: erm, what about the modeset things?
14:41 imirkin: karolherbst: nouveau.modeset=0 has to continue to work
14:42 karolherbst: imirkin: how is that affected when we remove that PCI device class check?
14:42 karolherbst: ohhhh
14:42 imirkin: karolherbst: just looking at your commit.
14:42 karolherbst: imirkin: look at the date of that commit
14:42 karolherbst: and the author....
14:43 imirkin: oh yeah.
14:43 karolherbst: it is just the commit which added that check
14:43 karolherbst: so it's broken for a long time now?
14:43 imirkin: so i guess we explicitly wanted to avoid running fbcon on those
14:43 imirkin: i thought you had just written that commit :)
14:45 karolherbst: it is nice when we come closer to the agreement that we can't trust shit, even the vbios is worthless sometimes
14:45 karolherbst: I am sure any patch removing that line will be followed by despair stating: "how the fuck do we workaround the GPUs with broken vbios, but no heads?"
14:49 jolar2: ok so things work better than ever, but not perfect
14:49 karolherbst: well
14:49 jolar2: if I undock, I am thrown out into gdm login screen
14:49 karolherbst: at least no crashes, right?
14:49 karolherbst: well kernel crashes
14:49 karolherbst: jolar2: yeah, because you need that modesetting DDX
14:49 karolherbst: not nouveau
14:49 imirkin: like i mentioned, nouveau DDX doesn't do connector hotplugging.
14:50 karolherbst: right, so it isn't suited for MST useage
14:50 imirkin: jolar2: if this is something you actively want, i can look into it over the weekend
14:50 imirkin: i suspect it should be trivial
14:50 jolar2: imirkin: I do
14:50 karolherbst: imirkin: sounds good :) I can test as well
14:50 imirkin: you'll have to test though - i don't have anything DP here
14:50 jolar2: I will
14:50 jolar2: :)
14:51 karolherbst: jolar2: well, for now check with the modesetting DDX though. It sould work with it
14:51 imirkin: (actually, i did recently gain a Quadro 400 which has a DP port. but iirc fermi only does 1.1, and even if it did, i have no DP sinks)
14:51 jolar2: karolherbst: I cannot use integrated graphics for external connectors, so I really need to use noveau
14:51 karolherbst: ...
14:51 karolherbst: again
14:51 jolar2: ? :)
14:51 imirkin: jolar2: xf86-video-modesetting will work on nouveau semi-ok
14:51 karolherbst: use modesetting
14:51 karolherbst: ;)
14:52 jolar2: hmm
14:52 imirkin: assuming that you have mesa installed
14:52 jolar2: cannot emerge that as it is blocked I think
14:52 karolherbst: you don't have to install it
14:52 jolar2: but I thought I _was_ using modesetting
14:53 karolherbst: it is inside xorg-server now
14:53 jolar2: since I removed any xorg.conf
14:53 jolar2: exactly
14:53 karolherbst: jolar2: I thought you had a xorg.conf?
14:53 karolherbst: ahh
14:53 karolherbst: then remove the nouveau ddx
14:53 imirkin: nouveau should get used by default
14:53 karolherbst: it is the easier way to get it
14:53 imirkin: add an xorg.conf which says Driver "modesetting"
14:54 jolar2: I'll test it
14:55 jolar2: ok, now I did that
14:55 jolar2: and no external displays
14:55 karolherbst: jolar2: well, I think you still need to specify everything else or so
14:55 jolar2: the only was I have managed to get external displays is: xrandr --setprovideroutputsource 1 0 *with* nouveau
14:55 karolherbst: no clue. the xorg.conf is super messy to get correct
14:56 jolar2: I'll try to remove nouveau instead then
14:56 jolar2: for now
14:56 jolar2: I'll remove xf86-video-nouveau
14:56 karolherbst: and the xorg.conf file as well
14:56 jolar2: yeah
14:56 karolherbst: there is one other issues though. I have no idea how to set it up through xrandr if not done automatically
14:57 karolherbst: ohh, I use intel for the intel GPU :D
14:57 karolherbst: no idea if two providers are shown if both are modestting? but probably?
14:57 tobijk: jolar2: if your output is driven by the nvidia card and not the internal intel (or whatever) you have to use xrandr --setpovideroutputsource 1 0
14:58 tobijk: it doesnt matter if you use nouveau or modesetting within the xserver
14:58 karolherbst: tobijk: does it work if both GPUs are driven by modesetting?
14:58 jolar2: xrandr --setprovideroutputsource 1 0 without nouveau does give 3 DP
14:58 tobijk: karolherbst: mh i think i have tried that onece, yet i'm not completely sure
14:58 jolar2: but... not the docking station connectors
14:58 jolar2: could it be the case that the docking station needs the nvidia card?
14:58 karolherbst: jolar2: even when docked?
14:58 jolar2: karolherbst: yes
14:58 karolherbst: try to redock
14:59 karolherbst: and plug in a display
14:59 jolar2: nope
14:59 jolar2: nothing
14:59 karolherbst: do you check with xrandr?
14:59 jolar2: yup
14:59 jolar2: they are not there
14:59 karolherbst: weird
14:59 jolar2: only DP-1-1 to DP-1-3
14:59 karolherbst: what does 'xrandr --listproviders" return?
15:00 karolherbst: two or one?
15:00 jolar2: two
15:00 jolar2: rovider 0: id: 0x7c cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 2 associated providers: 1 name:Intel
15:00 jolar2: Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 3 associated providers: 1 name:modesetting
15:00 karolherbst: mhh
15:00 karolherbst: I have 6 outputs
15:00 karolherbst: let me try something
15:01 tobijk: wait, i can check if it works with both modesetting
15:01 jolar2: could the docking station connectors be nvidia output only?
15:01 karolherbst: no
15:01 karolherbst: it should work
15:01 karolherbst: I had some troubles at first as well
15:01 tobijk: jolar2: it actually is possible, i have an hdmi which is only driven by the nvidia card
15:01 karolherbst: let me try to remember
15:02 karolherbst: jolar2: try to start X when the dock is connected
15:02 karolherbst: and see if that is any better
15:02 jolar2: karolherbst: that is what I did
15:02 jolar2: towo^work: it could be the case but it is then funny that the P50 and P51 differ in that way
15:03 jolar2: towo^work: sorry wrong guy, tobijk left, blame whoever invented tab-completion
15:03 imirkin: definitely not the guy who used it :)
15:04 jolar2: exactly
15:04 karolherbst: jolar2: try to stop X
15:04 karolherbst: undock
15:04 karolherbst: start X
15:04 karolherbst: dock
15:04 jolar2: karolherbst: ok
15:05 karolherbst: maybe even reboot, no idea if there can be any state being messed up inside the driver
15:05 jolar2: karolherbst: same thing
15:05 karolherbst: I know that it works since I booted without the nouveau DDX being loaded once
15:06 jolar2: all you know is that it works for P50
15:06 karolherbst: well
15:06 karolherbst: I had my issues as well
15:06 tobijk: both modesetting works fine for me
15:06 karolherbst: at some point there were gone
15:06 jolar2: tobijk: you have P51?
15:06 karolherbst: jolar2: I think you should really try to reboot once and see if it works then
15:07 tobijk: jolar2: no but driving an output with intel/nvidia modesetting/modesetting combination works
15:07 karolherbst: that's the last idea I have though
15:07 tobijk: with a output connected to the nivida card
15:07 jolar2: tobijk: that could work, but not possibly through the docking station according the outputs xrandr gives me right now
15:07 jolar2: karolherbst: ok
15:08 jolar2: karolherbst: I could remove the nouveau useflag and re-emerge stuff as well to be sure
15:08 karolherbst: no
15:08 karolherbst: not needed
15:09 karolherbst: when the xf86 driver is removed it should be fine
15:09 karolherbst: also
15:09 tobijk: jolar2: whats the xrandr output?
15:09 karolherbst: if you remove the nouveau flag, mesa won't have nouveau support
15:09 jolar2: tobijk: won't paste it all but, except for eDP1, I have:
15:09 jolar2: VIRTUAL1 disconnected (normal left inverted right x axis y axis)
15:09 jolar2: DP-1-1 disconnected (normal left inverted right x axis y axis)
15:09 jolar2: DP-1-2 disconnected (normal left inverted right x axis y axis)
15:09 jolar2: DP-1-3 disconnected (normal left inverted right x axis y axis)
15:10 jolar2: tobijk: and... when docking station displays are available, I get more displays
15:10 tobijk: do you actually have one listed below the second modesetting?
15:10 jolar2: tobijk: and... if I do not do the "xrandr --setprovideroutputsource 1 0"-thingy, I do not have DP1-1-X
15:10 tobijk: for me with setprovideroutput... https://hastebin.com/hepevihuju.go
15:11 jolar2: what computer and and what docking station?
15:12 tobijk: jolar2: no dock but a nvidia card driving an output with reverse-prime
15:12 karolherbst: well I also have my MST heads
15:12 karolherbst: DP-1-1-1 ... DP-1-1-3
15:13 jolar2: tobijk: then it is not really relevant :)
15:13 jolar2: tobijk: everything works fine but the docking stuff
15:13 tobijk: jolar2: if the dock is connected to the nivida card, it is
15:13 karolherbst: tobijk: it is ;)
15:14 karolherbst: jolar2: I am not quite sure if something needs to be set up for MST though
15:14 jolar2: me neither
15:14 jolar2: but honestly, I do not mind using nouveau for this
15:15 karolherbst: jolar2: did you try rebooting?
15:15 jolar2: nah will do now
15:15 tarragon: I've got the error!!
15:15 jolar2: just for fun, I will switch to the stable 4.12.12
15:15 karolherbst: jolar2: I am sure it will work if you boot with the dock connected...
15:15 karolherbst: jolar2: no
15:15 jolar2: ok
15:15 jolar2: no thne.
15:15 karolherbst: jolar2: because you need that kernel patch ;)
15:15 jolar2: karolherbst: ok
15:15 karolherbst: tarragon: which one?
15:15 jolar2: brb
15:18 tobijk: mh imirkin, didnt you mention a missing listener for dynamically adding a new output (such as a dock) yesterday?
15:19 tarragon: karolherbst: this one --> http://dpaste.com/0HMGX5D
15:19 tarragon: kernel 4.13
15:19 tarragon: first one hard lock.
15:19 jolar2: karolherbst: you are right, it does work with modesetting and booting with dock connected
15:19 karolherbst: jolar2: ;)
15:19 tarragon: with a game that never locked before.
15:20 jolar2: karolherbst: but the patch is still needed?
15:20 karolherbst: jolar2: yes
15:20 tarragon: right in the middel of a game BHAM!!
15:20 jolar2: so somehow, modesetting DDX accesses nouveau stuff
15:20 karolherbst: jolar2: and it would be really great if you try to upstream it yourself
15:20 karolherbst: jolar2: it uses kms
15:20 tobijk: jolar, care to show us your xrandr --listprovider output once again?
15:20 jolar2: tobijk: sure
15:20 karolherbst: and kms is implemented by nouveau
15:20 karolherbst: more or less
15:21 karolherbst: kms is just a more generic API
15:21 jolar2: Providers: number : 2
15:21 jolar2: Provider 0: id: 0xba cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 2 associated providers: 1 name:Intel
15:21 jolar2: Provider 1: id: 0x49 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 6 associated providers: 1 name:modesetting
15:21 tobijk: jolar2: pastebin it or so
15:21 jolar2: ah you mean xrandr only
15:21 karolherbst: and the modesetting DDX uses glamor for 2D acceleration, which uses OpenGL, which ends up using the nouveau parts within mesa
15:21 jolar2: complex stuff
15:21 karolherbst: yeah
15:22 karolherbst: it's for no reason one of the bigger things in linux :D
15:22 jolar2: karolherbst: what do you mean "upstream it yourself"?
15:22 jolar2: karolherbst: you mean send the patch to nouveau development?
15:22 karolherbst: jolar2: write the patch, send it to the ML, wait for skeggsb to accept it
15:22 karolherbst: well
15:22 jolar2: karolherbst: will do
15:22 karolherbst: you get reviews and sometimes you need to change stuff
15:22 jolar2: karolherbst: maybe not today, but this week
15:22 karolherbst: this entire thing is called upstreaming
15:23 karolherbst: yeah, it is fine
15:23 karolherbst: mhh
15:23 karolherbst: actually
15:23 jolar2: https://pastebin.com/rAiVkKG8
15:23 karolherbst: jolar2: before friday would be best...
15:23 jolar2: karolherbst: I'll see what I can do
15:23 karolherbst: jolar2: because 4.14 will be released this weekend most likely
15:24 karolherbst: and it would be perflect to have that patch in before that
15:24 jolar2: karolherbst: ok
15:24 karolherbst: it is fine for a .1 release
15:24 karolherbst: but even better for a .0
15:24 jolar2: ok
15:25 jolar2: karolherbst: ok, now I just want to test docking/undocking
15:25 jolar2: karolherbst: still in X when undocking
15:25 jolar2: karolherbst: now redocking...
15:27 tobijk: jolar2: if you boot docked, docking and undocking should work fine
15:27 tobijk: after that
15:27 karolherbst: you never know before trying
15:27 karolherbst: just like backups
15:28 karolherbst: you do backups, but do you know it works when you have to restore from it?
15:28 karolherbst: you tink it works, but sometimes... it does not
15:28 karolherbst: *think
15:28 tobijk: :D
15:29 tobijk: thats the only thing btrfs is good at
15:29 jolar2: tobijk: system hanged
15:29 tobijk: jolar2: oh well despited that :/
15:29 karolherbst: tobijk: well, you _think_ it works, until btrfs screws up again, which it does
15:29 jolar2: re-docking was fine, but hanged upon running "xrandr"
15:29 karolherbst: especially if your disc goes south
15:30 karolherbst: jolar2: well, don't call xrandr then :p
15:30 karolherbst: ...
15:30 jolar2: karolherbst: I would love not to, but when i redocked the external displays were off
15:30 karolherbst: it hangs for me for like 0.5 seconds as well
15:30 karolherbst: ohh
15:30 jolar2: let me patch 4.12.12 and see where it leads me
15:30 tobijk: so the nouveau kernel part is not completely sane when it comes to docks, well who would have guessed
15:30 karolherbst: tobijk: well, it works for me
15:31 tobijk: mhm
15:31 karolherbst: it might be that 4.14 has some fixes, which aren't in 4.13
15:31 tobijk: karolherbst: btw xrandr hangs for me as well for 0.5 sec
15:31 jolar2: a lot of intel fixed in 4.14 i heard
15:31 jolar2: fixes*
15:32 karolherbst: tobijk: pro tip: don't have all your backups on btrfs
15:32 tobijk: jolar2: did you get get the dmesg when the system hung when calling xrandr?
15:32 tobijk: karolherbst: hehe
15:33 jolar2: tobijk: not sure
15:34 tobijk: ah btw karolherbst the new vmm code did not help with tuxkart and my nv86 with 128mb
15:34 tobijk: still erros left and right :/
15:34 karolherbst: tobijk: sad
15:34 karolherbst: is it better though?
15:35 tobijk: karolherbst: yep a bit, the main menu is shown completely and not only parts of it
15:35 jolar2: just some messed up characters in dmesg
15:35 jolar2: ^@
15:35 karolherbst: well I was more thinking about the system not crashing
15:35 karolherbst: messed up characters are no good in dmesg
15:35 tobijk: karolherbst: when starting an actualy race it hangs
15:35 jolar2: well the system hanged
15:35 jolar2: so I would expect no less
15:36 karolherbst: jolar2: so the journal is messed up
15:36 jolar2: that is from kern.log
15:36 jolar2: yeah
15:36 karolherbst: meh
15:36 karolherbst: don't trust the journal
15:36 jolar2: now, 4.12.12
15:36 tobijk: jolar2: better go the other direction :>
15:36 tobijk: 4.14
15:36 jolar2: fine
15:38 tobijk: or even drm-next, if you dare :>
15:39 tarragon: karolherbst: was it helpful?
15:39 karolherbst: tarragon: not at all
15:39 tobijk: karolherbst: you forgot to add my r-b to your NULL check patch :P
15:40 karolherbst: tobijk: it basically tells us something went wrong
15:40 karolherbst: but why? no idea
15:40 karolherbst: tobijk: I didn't, ben just pushed it
15:40 tobijk: karolherbst: np, just saw it by chance
15:40 tarragon: wow
15:41 karolherbst: tarragon: most likely some MT mess up? or something else?
15:41 tarragon: karolherbst: how to get more info then?
15:41 karolherbst: hard to tell
15:41 tarragon: what's MT?
15:41 karolherbst: multi threading
15:41 tarragon: karolherbst: this only appeared with 4.13, and not with 4.9
15:41 tarragon: oookk...
15:41 karolherbst: well, have fun bisecting ;)
15:41 tarragon: karolherbst: so disable it?
15:41 karolherbst: well, I don
15:42 tarragon: could be libsdl2 threaded messing up with nouveau
15:42 karolherbst: 't know really
15:42 karolherbst: might be, might be not
15:42 tarragon: crap, I don't wanna get a lockup now :/
15:43 tarragon: I wonder if I can run another card and make nouveau lock up but with a still running system
15:43 tobijk: tarragon: actually that works for a while, then the system may hang as well :>
15:45 tarragon: :(
15:45 tarragon: what multi-threading is being the problem? kernel's, Xorg, glibc, libsdl, mesa???
15:46 imirkin: plasmashell, gnome is more likely.
15:46 Aristar: hrrm sofar no nouveau crashes on plasma5 with oxygen widget w/o animations. system defaults to GraphicsSystem=raster however which i believe makes QT stuff render with gpu raster
15:46 Aristar: widget theme*
15:47 tobijk: Aristar: just stay away from kde pim and you should be fine :)
15:47 Aristar: OGL3.1 compositor seemed to fallback to software but OGL2.0 compositor seems to work
15:47 Aristar: tobijk: does that use any gpu related stuff?
15:47 tarragon: I am getting errors abouth this OGL thingy, somethil like oogl.cpp
15:47 Aristar: awihle back i was debugging some kde git builds and installed like ALL of kde including all the multilib 32bit stuff
15:48 tarragon: where does that come from?
15:48 tobijk: Aristar: it uses a nice webengine whit threaded rendering, that upsets novueau a bit ;-)
15:49 Aristar: hmm, i know qupzilla disables stuff with nouveau detected, not sure about elsewhere. "Nouveau openGL driver detected. Qt WebEngine will disable usage of the GPU." [...] "Nouveau openGL drivers don't support multithreaded rendering"
15:50 tobijk: Aristar: well yeah then you have a version patched for that specifically
15:50 Aristar: it's just the latest qupzilla which released somewhat recently
15:51 jolar2: karolherbst, tobijk: 4.14-rc7 did not work well at all
15:51 tarragon: where does the OGL part come from?
15:51 jolar2: starting X hanged the system
15:51 Aristar: org.kde.falkon browser isn't quite ready yet and doesn't seem as recent on commits as qupzilla but they're in the process of merging it into falkon
15:51 tarragon: I feel my Xorg is going haywire
15:51 karolherbst: jolar2: even with your patch?
15:51 karolherbst: ohh wait.. unrelated...
15:51 karolherbst: jolar2: can you try rc8?
15:52 tobijk: karolherbst: nah i think he still has to apply it?!
15:52 jolar2: I of course applied my patch
15:52 karolherbst: tobijk: yeah, but for a different reason
15:52 Aristar: i believe X.Org 1.19.5 released recently, not sure of changelog
15:53 jolar2: I am now a 4.12.12
15:53 jolar2: at*
15:53 tobijk: Aristar: it did yeah
15:53 jolar2: (with the patch)
15:53 jolar2: and as with 4.13.9, I could start X and enable the external diplays
15:53 jolar2: now, when I undock and redock, xrandr does not crash the system
15:53 Aristar: X.Org 1.19.5/Mesa 17.2.4 here but i wish some of the nouveau nv50 commits made it into 17.2.4
15:54 tobijk: Aristar: 1.19.5 is just a bugfix release to fix CVE-2017-12176 - CVE-2017-12187
15:54 jolar2: and the external displays are available when i set provideroutputsource, but they appear as disconnected...
15:54 karolherbst: jolar2: well there went some nouveau fixes in for -rc8
15:54 Aristar: tobijk: ah right, now i remember actually reading the changelog. god i hate RPM distros (having to download the actual rpm to read the changelog)
15:55 jolar2: ok, I will try that, but then I have to do some real work
15:55 Aristar: why can't they implement the thing mageia does which downloads, reads requested info (changelogs, file lists, etc) and deletes
15:55 Aristar: maybe i should port whatever script that is they have hooked into mcc/rpmdrake
15:57 Aristar: i'm no fan of apt but it works and has sane utilities to query/search stuff
15:57 Aristar: like apt-file <3
15:59 Aristar: currently on opensuse testbed due to some contracted work, it's derp in a lot of ways though i can make any distro work for me with enough hacking and syncing my git bashrc/zshrc related stuff
16:03 Aristar: i'd be using nvidia binary driver if it was A: portable (this install is used on baremetal and also KVM, qemu, vbox, vmware, etc)) and B: versioning of nvidia-legacy on some boxes which doesn't work on my newer boxes. don't really mind closed source if it works though but too much BS
16:04 Aristar: dkms did work for nvidia on rpm distros, borrowed some scripts mageia uses to auto-rebuild on reboots if kernel changed before starting X. but that was only to dump some info
16:05 Aristar: (usually precompiled kmods are used)
16:06 Aristar: ...then there's the BS of having to switch xorg.conf.d files, though i suspect bumblebee could be configured to toggle between nouvea/nvidia and others
16:08 Aristar: most of the libdrm/mesa attention lately seems to be focused on AMD lately
16:11 Aristar: sorry for the rant, too much coffee evidently
16:12 jolar2: karolherbst: nah it is some kind of regression
16:12 jolar2: karolherbst: rc8 also hangs
16:12 karolherbst: meh
16:17 jolar2: karolherbst: perhaps that safe-guard is there for a good-reason
16:17 jolar2: karolherbst: removing it altogether is perhaps not a good idea?
16:17 karolherbst: jolar2: doubtful? maybe?
16:17 jolar2: I have no idea
16:18 jolar2: another funny thing
16:18 karolherbst: is something different if you don't apply your patch?
16:18 Aristar: hmm i guess kmscon is obsolete, last update 2014, not sure what the intention was or if it's obsolete due to wayland? not sure if it renders console too but i know on chrome os it handles both, weird its in opensuse and archlinux repos
16:18 jolar2: karolherbst: yeah think so, but don't have much more time to test today
16:19 jolar2: thank you for your time though, I think we made great progress
16:20 jolar2: ;5~;5~top
16:20 jolar2: hmm
16:20 Aristar: anyway sorry for the spam i'll quit the chatter for more important developer discussions
16:20 jolar2: shit is awfully slow now
16:20 karolherbst: jolar2: 4K display?
16:20 jolar2: with modesetting + external displays
16:20 jolar2: no
16:20 karolherbst: mhhh
16:21 karolherbst: *sigh* yeah no idea, it was kind of slow for me as well
16:21 karolherbst: maybe this is glamor doing shitty stuff or so
16:21 karolherbst: no idea
16:21 jolar2: maybe I should use noveau after all
16:22 Aristar: (speaking of glamour; is this limited to newer GPUs and falls back to dri2 stuff? I noticed X here is using dri2)
16:23 Aristar: (X11 was built with glamour support though)
16:24 Phillemann: I've been running nouveau with "07" as power management state for some time now and I'd like to enable it at boot. What's the correct kernel parameter to accomplish that?
16:25 jolar2: karolherbst: this is messy
16:25 jolar2: karolherbst: external displays work fine with nouveau but when I turn off the internal display X kind of hangs
16:27 jolar2: i am far from convinced that my patch fixes everything, and it may or may not cause instability issues, but for me it is of course better than before, and better than kernel crashse
16:38 Moiman: Phillemann: look https://nouveau.freedesktop.org/wiki/KernelModuleParameters/
16:39 Phillemann: Moiman: Yeah, I saw that, but was a little confused. Is it nouveau.config=NvClkMode=7?
16:39 Phillemann: Sorry, I'm not used to setting kernel parameters
16:43 Moiman: Phillemann: Yes that looks correct
16:48 Phillemann: Ah, thanks.
16:49 karolherbst: imirkin: did I accidentally fix that clocks being reset on resume?
16:50 imirkin_: Phillemann: out of curiousity, what does it boot to for you? 07 is pretty frequently the default anyways
16:51 Phillemann: There was a command to list the possible values, what was that again?
16:53 imirkin_: cat /path/to/pstate
16:54 Phillemann: The default is 0a
16:54 imirkin_: that's very surprising
16:54 imirkin_: what hw is this?
16:55 Phillemann: 07 saves me about ~7 degrees in heat :D
16:55 Phillemann: GeForce GTX 670MX
16:55 imirkin_: that's thoroughly surprising.
16:55 Phillemann: How so?
16:55 imirkin_: that it boots to 0a
16:55 Phillemann: And not 07?
16:56 imirkin_: i've never seen a kepler boot to anything but the lowest perf level
16:56 imirkin_: (except every so often there's a mega-low one)
16:56 Phillemann: Okay, I might have to correct myself. I manually set my pstate to 07. It might have booted to 07 and then changed.
16:56 imirkin_: it only changes when you change it
16:56 Phillemann: Ah, okay.
16:56 imirkin_: the default, btw, is whatever's listed in AC on boot
16:57 Phillemann: But the default is hard-coded into the GPU?
16:57 Phillemann: Or put differently, nvidia made the decision to not use 07?
16:57 imirkin_: the default is hard-coded into the vbios
16:58 imirkin_: on boot it runs various init which leaves the GPU in a particular state
16:58 imirkin_: which need not be any of the defined pstates btw
16:58 Phillemann: Oh, okay.
16:58 imirkin_: but often is
17:04 karolherbst: imirkin_, Phillemannit doesn't boot to 0a
17:04 karolherbst: it's just that the default voltage is higher than the actual required one for 07
17:04 karolherbst: so by clocking to 07, the voltage drops
17:04 karolherbst: which reduces the heat generation as well
17:14 imirkin_: ah that makes more sense
17:39 jolar2: karolherbst: I am writing a proper commit now
17:40 jolar2: karolherbst: what If I check, 0x0300, 0x0301 and 0x0302 in the init-function?
17:40 karolherbst: dunno
17:41 jolar2: feels safer
17:41 imirkin_: 0x03XX is always display
17:41 jolar2: and maybe even works with 4.14-rc8 ;)
17:41 imirkin_: and only that stuff matches nouveau in the first place
17:41 jolar2: so the safe-guard is useless?
17:42 imirkin_: pretty sure it was for some annoying situation where the stupid GPU didn't have a display block but had DCB connectors
17:42 jolar2: so we cannot enter the init-function with i915-stuff?
17:42 jolar2: ok
17:42 imirkin_: there's probably a different way of doing this
17:42 imirkin_: which will deal with both cases
17:42 imirkin_: or perhasp the code has been moved around enough since then that it just works
17:43 jolar2: I just don't want to commit garbage that destroys 4.14
17:44 imirkin_: yeah don't worry - zero chance of making it to 4.14
17:44 jolar2: or 4.15 for that matter
17:49 karolherbst: imirkin_: well, it is a bug fix. If we decide that it is safe enough, it can be added to 4.14
17:49 imirkin_: v4.14 is what it is.
17:49 karolherbst: k
17:50 jolar2: 4.15 then?
17:50 karolherbst: 4.14.x
17:50 karolherbst: maybe
17:53 jolar2: ok
17:58 jolar2: karolherbst: Something like this? https://pastebin.com/KFfjCLXU
17:59 karolherbst: jolar2: I think it is possible to add messages to BUG
18:00 jolar2: karolherbst: ok, not sure what to say more that it is a NULL dereferencing that should not happen
18:02 jolar2: karolherbst: I found one example of this.
18:02 jolar2: but that would mean I keep the if-clauses as you suggested and then write BUG_ON("blabla");?
18:03 jolar2: 19:00 jolar2: karolherbst: ok, not sure what to say more that it is a NULL dereferencing that should not happen
18:03 jolar2: 19:02 jolar2: karolherbst: I found one example of this.
18:04 jolar2: 19:02 jolar2: but that would mean I keep the if-clauses as you suggested and then write BUG_ON("blabla");?
18:07 jolar2: karolherbst: this patch worked better
18:07 jolar2: I am on modesetting
18:07 karolherbst: jolar2: I can't right now, in an hour I can talk
18:07 jolar2: with 3 displays
18:08 jolar2: ok
19:51 jolar2: karolherbst1: are you back?
19:54 jolar2: karolherbst1: I have seen BUG_ON with a string on some places in the linux kernel, but it is not super common (perhaps not intended?).
19:56 tobijk: jolar2: just leave the dmesg here (as a paste) and people will have a look at it :)
19:56 jolar2: tobijk: what?
19:56 jolar2: tobijk: I was discussing this patch https://pastebin.com/KFfjCLXU
19:56 tobijk: if there is a BUG_ON and you did hit it, it should show up in dmesg
19:57 jolar2: yeah, but I think karolherbst1 wanted me to add a message to the BUG_ON
19:57 jolar2: if that patch looks fine I will submit it to the ML
19:58 tobijk: meh, i'm not much for BUG_ON, yet other people wil lrule different
19:59 jolar2: personally, I would like to add some kind of safe-guard, be it BUG_ON or whatever
19:59 jolar2: i915 uses an if-clause
19:59 tobijk: that'd be more to my personal liking,
20:00 tobijk: but lets see what karol thinks about it :)
20:00 jolar2: that is what I had to begin with, but that only hides an underlying error
20:00 jolar2: yeah
20:00 jolar2: i'll keep irssi running
20:00 jolar2: I think the patch is sound otherwise, and it does work with 4.14-rc8 for me
20:01 karolherbst1: jolar2: yeah, now I am back
20:01 tobijk: jolar2: yeah the other line looks good to me
20:01 jolar2: karolherbst1: so what is your verdict?
20:01 jolar2: :)
20:02 karolherbst1: jolar2: ahh, sorry, that BUG_ON thing is actually wrong
20:02 karolherbst: use WARN_ON
20:03 tobijk: karolherbst: can we at least hide it behind some debug clause :>
20:03 karolherbst: or WARN_ON_ONCE
20:03 karolherbst: no
20:03 jolar2: karolherbst: but then the kernel crash would occur right?
20:03 karolherbst: use WARN_ON_ONCE
20:03 karolherbst: no
20:03 karolherbst: ohh wait
20:03 karolherbst: mhhh
20:03 karolherbst: messy
20:03 karolherbst: well you would do an if around that
20:04 jolar2: ok, but just as BUG_ON, I do not think WARN_ON was intended for messages
20:04 karolherbst: don't use BUG_ON
20:05 karolherbst: BUG_ON is for cases where you really don't want to handle that issue
20:05 karolherbst: like if handling the condition would take too much of work
20:05 jolar2: ok, hold on, I will make a new patch
20:06 tobijk: karolherbst: i dont see why this is not handled by a special clean-up case
20:06 tobijk: a yet to create one
20:06 karolherbst: well
20:06 karolherbst: we could also do a warning somehow
20:06 karolherbst: but this is outside of nvkm
20:07 karolherbst: ahh NV_ERROR
20:07 jolar2: if(drm->fbcon)
20:07 jolar2: drm_fb_helper_remove_one_connector(&drm->fbcon->helper, &mstc->connector);
20:07 jolar2: else
20:07 jolar2: WARN_ON(!drm->fbcon);
20:07 jolar2: ?
20:07 tobijk: jolar2: NV_WARN if its there
20:07 karolherbst: jolar2: well, I think what is best is to use NV_ERROR and return -ESOMETHING
20:08 jolar2: this is a void function
20:08 karolherbst: then return nothing
20:08 tobijk: :D
20:08 jolar2: nono
20:08 jolar2: I have to release the mutex lock
20:08 karolherbst: the point is, we shouldn't continue and throw an error
20:08 karolherbst: that as well
20:08 karolherbst: yeah, well, do the right thing then
20:09 tobijk: so, thowing a WARN is enough imho
20:09 jolar2: I am not sure we can (I do not know how) at that place
20:09 jolar2: I'll do NV_WARN
20:09 karolherbst: jolar2: "goto" like every other "sane" C kernel dev does
20:09 jolar2: lol
20:10 tobijk: hue? goto has its places, but not here
20:10 karolherbst: tobijk: to unlock a mutex?
20:10 karolherbst: it depends, but usually those things are last in a function
20:10 tobijk: you have to unlock it in every case? no?
20:10 jolar2: thing is, the mutex is unlocked and then the connector is registered at the bottom
20:11 jolar2: so... this will be an if-else construction
20:11 karolherbst: tobijk: if you lock it?
20:11 karolherbst: uhm...
20:11 karolherbst: let me read that function again
20:12 jolar2: or... I keep the code pretty much as it is, but add NV_WARN instead, since that code is tested.
20:12 jolar2: as long as we do not do dereference a NULL pointer
20:12 jolar2: we are fine
20:12 jolar2: ... ish
20:12 tobijk: jolar2: oh that func is short, so yeah having a goto is fine :D
20:12 karolherbst: mhhh
20:12 karolherbst: I would actually love to have a place higher up
20:14 jolar2: this is what you get
20:14 tobijk: jolar2: do what intel does in intel_dp_mst.c:484
20:15 jolar2: ok
20:15 jolar2: that is what I do now
20:15 jolar2: or, before I introduced BUG_ON
20:16 tobijk: karolherbst: if you want it at a higer place, you'd have to change all drivers
20:16 jolar2: but then drm_connector_register is invoked even though there is NULL-pointing fbcon
20:16 tobijk: yet could be worth it
20:17 karolherbst: tobijk: maybe, maybe not
20:18 jolar2: ok two options: 1. do like intel do 2. call NV_WARN, unlock the mutex and return
20:18 jolar2: or maybe do like intel do + NV_WARN
20:18 karolherbst: and the unreference as well? or do it before all that and just return
20:19 jolar2: what is the mutex for?
20:19 jolar2: do I need to mutex lock to peek at drm->fbcon?
20:19 karolherbst: no
20:19 jolar2: ok, then I agree
20:20 jolar2: call NV_WARN and just return
20:20 jolar2: I'll do the same in nv50_mstm_destroy_connector then
20:20 jolar2: both are necessary according to my personal experience...
20:30 jolar2: karolherbst: https://pastebin.com/4AbPA7hq
20:31 imirkin_: that has the same effect as removing the check
20:32 imirkin_: it can only ever be VGA or 3D
20:32 jolar2: this does bring up another question then... should intel really register connectors if their fbdev is pointing to NULL?
20:32 jolar2: imirkin_: I have 3D...
20:32 tobijk: jolar2: AMD is doing it as well
20:32 imirkin_: that's my point
20:32 imirkin_: previously the check was effectively "!= 3D"
20:32 imirkin_: now you've made it "!= 3D || == 3D"
20:32 tobijk: maybe haivng a connector without fbdev is ok? not sure
20:33 jolar2: imirkin_: I may remember wrong, but, I experienced problems when I removed the check altogether
20:33 imirkin_: well, you still want the !num_crtcs check
20:33 jolar2: imirkin_: i kept it
20:33 jolar2: imirkin_: I mean the other check
20:33 jolar2: tobijk: me neither
20:33 imirkin_: then it should have the same effect.
20:34 jolar2: if you are 100 % sure about this, then I agree
20:34 imirkin_: i am.
20:34 jolar2: this also mean I remember incorrectly or did something wrong
20:34 jolar2: means*
20:34 jolar2: because it cannot be true at the same time as your assertion
20:34 jolar2: hmm
20:35 jolar2: well, cannot test now without the docking station
20:35 imirkin_: you'll have a good time with "this statement is false" then :)
20:35 jolar2: that's just plain evil
20:36 tobijk: jolar2: btw, splitting the patch would be useful, have the fbdev check as prerequisite
20:36 jolar2: messing with logic
20:36 imirkin_: there's a star trek episode about that...
20:36 jolar2: hmm TNG?
20:37 jolar2: or original series?
20:37 imirkin_: original. nomad.
20:37 imirkin_: https://www.youtube.com/watch?v=G6o881n35GU
20:37 jolar2: I bet I have seen it, but not sure I remember the contents
20:37 imirkin_: more recently remade in a south park
20:38 jolar2: now I 'member
20:38 jolar2: ;)
20:40 jolar2: not the south park episode though
20:40 imirkin_: south park was about funny-bot
20:41 jolar2: ok
20:41 imirkin_: https://www.youtube.com/watch?v=vzlV4AeQ_8s
20:42 imirkin_: this is better - https://www.youtube.com/watch?v=rtDh7FUshxo
20:43 jolar2: true ripoff of star trek
20:43 jolar2: :D
20:43 jolar2: well, anyway, I'll try out removing the condition altogether
20:44 jolar2: if it does not work I'll submit the patch as is, but perhaps split into 2 commits
20:46 imirkin_: a ton of stuff is a rip off of star trek, or early dr who, or the twilight zone
20:49 jolar2: I still love it