similar to: [Bug 23200] New: nv50/NVS135M: no working suspend yet

http://bugs.freedesktop.org/show_bug.cgi?id=23198 Summary: nv50/NVS135M: video hangs/flickers when fullscreen Product: xorg Version: 7.3 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

http://bugs.freedesktop.org/show_bug.cgi?id=23199 Summary: nv50/NVS135M: missing TV-out-support Product: xorg Version: 7.3 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy:

http://bugs.freedesktop.org/show_bug.cgi?id=23197 Summary: nv50/NVS135M: laptop runs hot Product: xorg Version: 7.3 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy:

Hi, [This is an automated email] This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all The bot has tested the following trees: v5.5.3, v5.4.19, v4.19.103, v4.14.170, v4.9.213, v4.4.213. v5.5.3: Failed to apply! Possible dependencies: 5ff0cb1ce253 ("drm/nouveau/kms/nv50-: Use less encoders by

Not entirely sure why this never came up when I originally tested this (maybe some BIOSes already have this setup?) but the ->caps_init vfunc appears to cause the display engine to throw an exception on driver init, at least on my ThinkPad P72: nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b This is magic nvidia speak for "You need to have the DMA notifier

Not entirely sure why this never came up when I originally tested this (maybe some BIOSes already have this setup?) but the ->caps_init vfunc appears to cause the display engine to throw an exception on driver init, at least on my ThinkPad P72: nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b This is magic nvidia speak for "You need to have the DMA notifier

Hi, all I'm trying to implement kms for pre-nv50 in last cuples of days. My current work[1] is based on the code of nv50 kms & ddx. Basicly, I just blindly port the code to kernel land :). I think I'm getting very close to working state, but it still doesn't work. Current state: 1) vbios parser is synced with ddx 2) i2c works 3) Something shows on internel LVDS panel and

Hello, Been wondering why I could never resume from s2r. That's because I always use 3D accel (compiz, cairo-dock). I have tested each Arch kernel releases, hoping each time to get s2r to work. Tired of this, I decided to use 3.4 LTS... 3.4.50 ... And guess what ? I could resume from suspend to RAM 100% of the time !!! I know it may be a hard work for you, but suspend to RAM while using 3D

Hi! On v4.18-rc1, the mouse cursor is missing on my right monitor. Card is G98 [GeForce 8400 GS Rev. 2]. I have two monitors: one small landscape 1280x1024 on DVI-I-1 left, and one big 1600x1200 (1200x1600 portrait) on HDMI-1 right. Curiously, the cursor is missing not only with proper xrandr setup after logging in but even in mirrored mode at the lightdm greeter[1]. How is this even possible

https://bugs.freedesktop.org/show_bug.cgi?id=55450 Priority: medium Bug ID: 55450 Assignee: nouveau at lists.freedesktop.org Summary: nouveau driver fails to restore screen content / video mode after resume from s2ram QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified

Not entirely sure why this never came up when I originally tested this (maybe some BIOSes already have this setup?) but the ->caps_init vfunc appears to cause the display engine to throw an exception on driver init, at least on my ThinkPad P72: nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b This is magic nvidia speak for "You need to have the DMA notifier

Not entirely sure why this never came up when I originally tested this (maybe some BIOSes already have this setup?) but the ->caps_init vfunc appears to cause the display engine to throw an exception on driver init, at least on my ThinkPad P72: nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b This is magic nvidia speak for "You need to have the DMA notifier

drivers/gpu/drm/nouveau/dispnv50/disp.c: In function nv50_pior_enable: drivers/gpu/drm/nouveau/dispnv50/disp.c:1672:28: warning: variable nv_connector set but not used [-Wunused-but-set-variable] commit ac2d9275f371 ("drm/nouveau/kms/nv50-: Store the bpc we're using in nv50_head_atom") left behind this. Reported-by: Hulk Robot <hulkci at huawei.com> Signed-off-by: YueHaibing

While I thought I had this correct (since it actually did reject modes like I expected during testing), Ville Syrjala from Intel pointed out that the logic here isn't correct. max_clock refers to the max symbol rate supported by the encoder, so limiting clock to ds_clock using max() doesn't make sense. Additionally, we want to check against 6bpc for the time being since that's the

On Tue, 25 Aug 2020 at 04:33, Lyude Paul <lyude at redhat.com> wrote: > > Not entirely sure why this never came up when I originally tested this > (maybe some BIOSes already have this setup?) but the ->caps_init vfunc > appears to cause the display engine to throw an exception on driver > init, at least on my ThinkPad P72: > > nouveau 0000:01:00.0: disp: chid 0 mthd

http://bugs.freedesktop.org/show_bug.cgi?id=16736 Summary: NVS 135M not supported Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy:

On Mon, Nov 02, 2015 at 04:45:00PM +0900, Michel Dänzer wrote: > On 31.10.2015 06:55, Daniel Vetter wrote: > > Apparently pre-nv50 pageflip events happen before the actual vblank > > period. Therefore that functionality got semi-disabled in > > > > commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28 > > Author: Mario Kleiner <mario.kleiner.de at gmail.com> >

On Mon, 2020-09-28 at 16:01 +0300, Ville Syrj?l? wrote: > On Tue, Sep 22, 2020 at 05:05:10PM -0400, Lyude Paul wrote: > > While I thought I had this correct (since it actually did reject modes > > like I expected during testing), Ville Syrjala from Intel pointed out > > that the logic here isn't correct. max_clock refers to the max symbol > > rate supported by the

Ville also pointed out that I got a lot of the logic here wrong as well, whoops. While I don't think anyone's likely using 3D output with nouveau, the next patch will make nouveau_conn_mode_valid() make a lot less sense. So, let's just get rid of it and open-code it like before, while taking care to move the 3D frame packing calculations on the dot clock into the right place.

It turns out that I forgot to go through and make sure that I converted all encoder callbacks to use atomic_enable/atomic_disable(), so let's go and actually do that. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Kirill A. Shutemov <kirill at shutemov.name> Fixes: 09838c4efe9a ("drm/nouveau/kms: Search for encoders' connectors properly") ---