17:25wyattbx: Hi I have a problem with new install kubuntu 20.10 and using nouveau. My laptop has an intel and nvidia. I enabled nouveau works except there is a quirk when using external monitor. When I try to move a window to external (HDMI) monitor it will not allow me unless I set up the primary latop monitor to the higest resolution. It is annoying because
17:25wyattbx: on the laptop the high resolution the letters are small and hard to read. Any ideas why?
17:28RSpliet: wyattbx: that's oddly specific. Is the external monitor connected to the NVIDIA GPU or the Intel IGP?
17:28wyattbx: HDMI and yes Nvidia
17:29wyattbx: Wait how can i double check. would inxi show it?
17:29wyattbx: Graphics: Device-1: Intel 4th Gen Core Processor Integrated Graphics driver: i915 v: kernel Device-2: NVIDIA GK104M [GeForce GTX 870M] driver: nouveau v: kernel Display: x11 server: X.Org 1.20.9 driver: modesetting unloaded: fbdev,vesa resolution: 1: 2880x1620~60Hz 2: 1920x1080~60Hz OpenGL: renderer:
17:29wyattbx: Mesa DRI Intel HD Graphics 4600 (HSW GT2) v: 4.5 Mesa 20.2.1
17:30RSpliet: wyattbx: can you upload your dmesg and xorg.0.log to a paste website and share here?
17:30RSpliet: please don't grep or filter these logs
17:30RSpliet: I think xrandr should be able to tell you
17:32RSpliet: both are equally possible by the way (HDMI on i915 or on NVIDIA), it's just up to the OEM
17:32wyattbx: what should i use pastebin?
17:32RSpliet: for example yes. Can't/shouldn't copy paste long logs into IRC :-)
17:33RSpliet: but if you prefer hastebin/fpaste/whatever go for it, doesn't matter much
17:35wyattbx: https://hastebin.com/amilajoguy.yaml thats dmesg
17:35RSpliet: Ubuntu 20.04 sounds like you may have to use journalctl to extract the Xorg log if it doesn't just exist in /var/log. Not 100% sure how that's done on Ubuntu tbh
17:36wyattbx: Thats xorg
17:36wyattbx: its 20.10 by the way
17:36RSpliet: Oh sorry, yes
17:37wyattbx: plasma kde if it matters
17:37RSpliet: Not for modesetting, just for stability :-P
17:38RSpliet: Ok, so indeed HDMI on the NVIDIA GPU. Xorg.log even mentions that quirk
17:38RSpliet: "[ 5960.961] (II) modeset(0): EDID quirk: Use maximum size instead of detailed timing sizes."
17:38RSpliet: Which is coming from i915
17:38wyattbx: ha i called by right name
17:39RSpliet: Given how long I haven't been active in this community, you might know things better than I do :-P
17:40RSpliet: Funny, googling that string gives all sorts of hits
17:40RSpliet: All with the panel identifying itself as EDID vendor "MEI", prod id 38562
17:41RSpliet: Was hoping to find the code responsible for that quirk...
17:41wyattbx: what does modeset mean?
17:42RSpliet: changing the display resolution
17:43RSpliet: It's a bit more involved than just saying x wide, y high (sadly)
17:43RSpliet: Ok, so the quirk is identified in the source as "Detailed timing descriptors have bogus size values, so just take the maximum size and use that."
17:43wyattbx: oh boy sounds like just surrender
17:44RSpliet: weirdly, I don't see a "MEI" display in that list
17:45wyattbx: should i redo the logs?
17:45RSpliet: Oh I'm sure your logs are fine
17:46wyattbx: i wonder if i can make th hdmi be the intel and the internal be the nvidia
17:49RSpliet: Sadly that's all hard-wired
17:49RSpliet: It'd be best if both HDMI and internal was on Intel :-)
17:50RSpliet: Anyway, I can't seem to identify the source of this quirk
17:50wyattbx: How can I force that
17:50wyattbx: nvidia drivers have other issues.
17:52RSpliet: Maybe I'm looking at the wrong quirk list
17:52RSpliet: and should be looking at the modeset driver :-)
17:57RSpliet: wyattbx: ah here we go. The panel in your laptop doesn't actually support most of the modes it reports
17:57RSpliet: See https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/modes/xf86EdidModes.c#L167
17:58RSpliet: Ok, so that establishes why your laptop panel should be in its highest resolution
17:58wyattbx: Well, so now how to fix :)
17:59RSpliet: Yeah... so what I'd recommend, and it might sound silly, is to keep your laptop in its highest resolution
17:59RSpliet: And see if you can scale the GUI
17:59RSpliet: to have larger fonts and controls
18:00wyattbx: ya, that is gonna be weird.
18:00wyattbx: these things never scale right
18:00RSpliet: Why? I expect you'll end up with a sharper image than when you use a lower resolution
18:01wyattbx: ill give it a try, but is there a way to force nvidia be first and the hdmi to be intel?
18:01RSpliet: because at the end of the day, the panel will actually have as many pixels in a row as it reports in it's highest res. Lower res will do weird upscaling inside the panel, which is hardly ever good
18:01RSpliet: No sorry, displays are hard-wired to their GPUs
18:01RSpliet: Unless you have one of the very few models in which you can disable the intel igp completely in the UEFO
18:01RSpliet: but... that's about as much control as you'll get
18:01RSpliet: that being said, I feel your pain with scaling controls
18:02RSpliet: story time
18:02RSpliet: I have a TV behind me which is 32", connected through HDMI to my desktop
18:02RSpliet: Now, for some reason the EDID of that TV reports "oh yeah, I'm 7 inch"
18:02RSpliet: QT takes that to heart
18:02RSpliet: and scales up *all controls* by a factor 5
18:03RSpliet: So whenever I drag VLC to that screen to watch a film, I can fit like 4 buttons on the screen and the actual film is poststamp size :-D
18:03wyattbx: The Display Configuration has a setting called Global Scale
18:03RSpliet: I think it got fixed very recently (idk how)
18:04RSpliet: wyattbx: hopefully that works! Otherwise there's a QT configuration tool that you can use to pick sizes and font settings
18:04wyattbx: I thank you for your time. At least now I have some guidance.
18:04RSpliet: It should be a lot better than it used to, at least in the gnome world they converted all icons to SVG so they can scale fine
18:04RSpliet: I only presume the Plasma world is ahead of Gnome ;-)
18:05wyattbx: I think KDE is SVG
18:05RSpliet: Yeah exactly. Give it a try, if it doesn't work we can come up with another strategy
18:05wyattbx: is there a regular forum to post things to?
18:05RSpliet: But I only assume the quirk is there for a reason
18:05RSpliet: Well, not really
18:06RSpliet: It's a tricky one, because your problem is one part "core DRM and xf86 stuff", which is #dri-devel territory
18:06RSpliet: On intel, which is #intel-gfx
18:06RSpliet: So... consider yourself lucky I got curious :-P
18:06wyattbx: weirdly this works with nvidia drivers. And I appreciate it
18:07wyattbx: Have a good day
18:07RSpliet: You as well!
18:35tandpijn: how does reclocking works on noveau driver? I'm struggling with unstable overclocked card :(
18:46tandpijn: I have Quadro FX3700M from lenovo and the extra mV are writen to the vbios. I have rom with corrected values but the nvflash tool refuses to work with this card. I wonder if there is any way around
18:57RSpliet: tandpijn: oh yeah nouveau isn't going to be able to change the (DRAM) clock speed on a G92
18:57RSpliet: changing all other clocks but not DRAM can lead to instability
19:01tandpijn: the clocks are set to factory value, problem is there is 1,03V set. I dunno if it's applied to DRAM or chip
19:02tandpijn: should be 1V according to some table I've found online
19:18tandpijn: I'm happy with nouveau because with your driver there are no shutdowns and damage to battery. But if I'm on windows then these things happen all the time when driver asks the gpu for more computations. There is a tool called nibbitor that allows to manipulate clocks and voltages hardcoded in VBIOS. There I have learned my VBIOS has this P4 voltage set to 1,03 instead of 1V
19:19tandpijn: I think about flashing it externally but before I start I wanted to ask if you know of any way around it
19:21RSpliet: I can't remember the exact VBIOS structure for those cards
19:21RSpliet: But I think there's no knobs that allow such fine tuning of voltages
19:22RSpliet: Not the DRAM voltage for sure, that was like max. 5 GPIO pins (so 32 discrete modes), most GPUs only had one or two hooked up
19:22RSpliet: Ehhh, unless there was an external voltage regulator on the I2C bus or sth
19:24RSpliet: mupuf: do you remember anything about voltages on G92?
19:25tandpijn: I'm totally noob about hardware principles ;-) point is the VBIOS has these values coded and this particular binary data on my card has it set to 1,03V
19:26RSpliet: tandpijn: yes, but there is a chance that the VBIOS just says "okay so voltage value 0x1337 means 1.03V". You can change that to 1V, but that's not going to change anything except how the driver reports your voltage
19:26tandpijn: I made corrected image but I cant flash it yet, nvflash says no nvidia adaptor found on this computer
19:27RSpliet: Can you run that corrected VBIOS through NVBIOS and paste the output... anywhere. like pastebin/hastebin/fpaste/...
19:27RSpliet: Somewhere there's an online nvbios tool, but I forgot where :-P
19:27tandpijn: I haven't build the envy yet
19:27tandpijn: I'm missing something to make it
19:28RSpliet: most likely libpcidev or something like that
19:28RSpliet: or some XML tools
19:28RSpliet: Anyway, Fedora has a package for it, I think Arch as well
19:29RSpliet: there may be a route of less resistance :-)
19:30tandpijn: debian hasn't :/
19:30tandpijn: I may paste the hexdump -C
19:31tandpijn: ~4k lines
19:32RSpliet: There we are. On-line nvbios parser
19:33tandpijn: https://pastebin.pl/view/b890ea4c hexdump
19:33tandpijn: https://pastebin.pl/view/cc5916a6 online tool
19:34tandpijn: both dumps are unmodified VBIOS
19:35RSpliet: ok right, yes indeed
19:35tandpijn: after tweak the bits changed at 0x0000d330 and 0000fbf0
19:36RSpliet: Okay, the d330 change sounds about right
19:37RSpliet: fbf0 not sure, unless that's a checksum
19:37RSpliet: The d330 change will have no effect on nouveau
19:37tandpijn: its the very end so it must be checksum
19:38tandpijn: which worries me since its tpm machine
19:39mupuf: RSpliet, tandpijn: Yeah, the voltage resolution wasquite poor back in the days
19:39mupuf: PWM came with maxwell IIRC
19:40RSpliet: mupuf: Thanks! I gave his VBIOS a coup d'oueil, looks like there is both a 1V and an 1.03V entry for the RAM
19:41RSpliet: tandpijn: somewhere in the init scripts there's a GPIO write that sets the voltage bits. Change the script to set VSEL0 to 1 instead of 0 and you should be golden on nouveau
19:41RSpliet: Problem is... I forgot which register is the GPIO register
19:42tandpijn: but this extra 3mV iss seemingly too much for my battery
19:42RSpliet: It's 30mV actually ;-)
19:43tandpijn: computer shuts down and battery connector melts
19:43tandpijn: ok, 30mV
19:43tandpijn: 3dV ;=)
19:43RSpliet: nouveau does not use the performance tables, because it doesn't support changing the clocks on G92. There's code upstream that works for some G98, but not nearly all. Code for G92 should be similar, but nobody invested in getting it up to speed
19:43RSpliet: (by the way, your nickname screams "Dutch/Flemish", but your hostname says "Polish". I'm confused :-P)
19:44tandpijn: I want to have it hardcoded to 1000mv
19:44RSpliet: tandpijn: your d330 change is half the story, and would actually work with NVIDIA's driver. But not nouveau, because we suck
19:45tandpijn: thats okm as I said I don't have any issue with nouveau driver
19:45tandpijn: it's windows driver that has this problem
19:46tandpijn: sometimes I turn windows but then I have to be connected to psu
19:46RSpliet: Ah ok, so in that case your change should be fine!
19:46tandpijn: otherwise it effectivly shutsdown
19:46RSpliet: Not sure what the fbf0 change is all about
19:47RSpliet: But I guess that doesn't matter. We always used byte 5 or sth to stick the checksum in, but it's really just "all bytes added must modulo to 0"
19:47RSpliet: so any byte is a checksum byte :-D
19:47RSpliet: if you're brave enough
19:47tandpijn: I'm quite certain it's the checksum it's used by TPM
19:47RSpliet: I don't know anything about TPMs, and at this point I'm too afraid to ask
19:48tandpijn: brave I'm not ;]
19:48tandpijn: Trusted Platform Modulem technology that watches user doesn't flash vbios
19:49tandpijn: very informative
19:49RSpliet: Ah... right. I'm afraid such stuff is beyond what nouveau people normally deal with
19:49RSpliet: I've never had to flash a VBIOS
19:49RSpliet: and I reverse engineered this stuff back in the days
19:50tandpijn: I wonder why nvflash refuses to recognize this adapter
19:50RSpliet: (not taking all the creds, mupuf was my partner in crime back then ;-) and many others contributed)