similar to: crtc not turned off after X shutdown?

Hi, I am considering the following setup: dom0 for normal, direct connection to the internet, use, and dom1 to be used when some one needs to connect to work through a VPN. Both domains will be running GNU/Linux with xen-modified kernels. I can''t use VNC to access dom1''s X server as it relies on an open network connection from dom1 to dom0: as soon as dom1 connects via the VPN,

On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote: > On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner <lukas at wunner.de> wrote: > > On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote: > >> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: > >> > When a drm_crtc structure is destroyed with drm_crtc_cleanup(), the DRM >

On Wed, Jun 01, 2016 at 04:40:12PM +0200, Daniel Vetter wrote: > On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote: > > On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote: > > > On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner <lukas at wunner.de> wrote: > > > > On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote: > > >

On Sun, Jan 19, 2014 at 4:18 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > Also make nv_lockvgac work for nv50+ devices. This should fix IO_CONDITION and > related VBIOS opcodes that read/write the crtc regs. > > See https://bugs.freedesktop.org/show_bug.cgi?id=60680 > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > > Ben, is this what you

That's great -- can you just confirm that this is what you did (every so often things work for the wrong reasons): (a) grabbed the ~darktama repo (b) took the MXM patch, futzed with the paths (since it was against the linux tree), applied it (c) took the patch off the mailing list, applied it (paths should have been fine) (d) DID NOT apply the vbios-pq1 patch in any form And then you built

On Fri, Jun 03, 2016 at 09:30:06AM +0200, Lukas Wunner wrote: > On Wed, Jun 01, 2016 at 04:40:12PM +0200, Daniel Vetter wrote: > > On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote: > > > On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote: > > > > On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner <lukas at wunner.de> wrote: > > > >

On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner <lukas at wunner.de> wrote: > > On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote: >> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: >> > When a drm_crtc structure is destroyed with drm_crtc_cleanup(), the DRM >> > core does not turn off the crtc first and neither do the drivers. With

Also make nv_lockvgac work for nv50+ devices. This should fix IO_CONDITION and related VBIOS opcodes that read/write the crtc regs. See https://bugs.freedesktop.org/show_bug.cgi?id=60680 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Ben, is this what you had in mind? I haven't gotten a chance to test this yet since your tree doesn't build against mine (which is largely

On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote: > On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote: > > On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner <lukas at wunner.de> wrote: > > > On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote: > > >> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: > > >>

Another problem I'm experiencing is that when I switch to the console and switch back to the desktop (vt7) it is all black, some colour remaining of the bottom panel exists for a couple of pixels along the bottom of the screen. My console is running frame buffer and gensplash. I've got compiz running with my ATI driver, and xorg 7.1.1 Is there a known bug between the frame buffer and Xgl?

http://bugs.freedesktop.org/show_bug.cgi?id=27398 Summary: displayport: x server does not draw anything on ThinkPad T410 Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau AssignedTo:

No problem. I applied the patch (plus the other for the MXM issue), replaced the preexisting nouveau.ko.gz in /lib/mod/? with the new gzipped one, and rebuilt the initramfs. (With an updated DRIVER_DATE define just to be sure.) The HDMI output works fine. Attached are the dmesg outputs before and after, grepped for 'nouveau'. As you can see, there's no real change. On Sun, Jan 19,

VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert msm over. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 2 ++ drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 2 ++ drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 15 ++++++++++ drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c

When a drm_crtc structure is destroyed with drm_crtc_cleanup(), the DRM core does not turn off the crtc first and neither do the drivers. With nouveau, radeon and amdgpu, this causes a runtime pm ref to be leaked on driver unload if at least one crtc was enabled. (See usage of have_disp_power_ref in nouveau_crtc_set_config(), radeon_crtc_set_config() and amdgpu_crtc_set_config()). Fixes:

Hi Daniel, On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote: > On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: > > When a drm_crtc structure is destroyed with drm_crtc_cleanup(), the DRM > > core does not turn off the crtc first and neither do the drivers. With > > nouveau, radeon and amdgpu, this causes a runtime pm ref to be leaked on > >

Good evening Daniel, On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote: > On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: > > When a drm_crtc structure is destroyed with drm_crtc_cleanup(), the DRM > > core does not turn off the crtc first and neither do the drivers. With > > nouveau, radeon and amdgpu, this causes a runtime pm ref to be leaked on

http://bugs.freedesktop.org/show_bug.cgi?id=20990 Summary: [kms] Change to VT broken with NV92 Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

On Wed, Jun 21, 2017 at 04:59:31PM +0900, Michel Dänzer wrote: > On 21/06/17 04:38 PM, Daniel Vetter wrote: > > On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote: > >> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get > >> totally obsolete. > >> > >> I think the gamma_store can end up invalid on error. But the way I read

On Thu, Jun 22, 2017 at 10:48:10AM +0200, Peter Rosin wrote: > On 2017-06-22 08:36, Daniel Vetter wrote: > > On Wed, Jun 21, 2017 at 11:40:52AM +0200, Peter Rosin wrote: > >> On 2017-06-21 09:38, Daniel Vetter wrote: > >>> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote: > >>>> This makes the redundant fb helpers .load_lut, .gamma_set and

https://bugs.freedesktop.org/show_bug.cgi?id=80675 Priority: medium Bug ID: 80675 Assignee: nouveau at lists.freedesktop.org Summary: KMS FB hand-over: no/black console on Nvidia MCP78S/C77/GeForce 8300 (10de:0848), X11 ok QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified