similar to: LUT update skipped on first modeset?

After analyzing verbose nouveau & drm dmesg, I have found seemingly no more useful details pertaining to having no TV-1 device. The TV-1 device might be getting lost within DRM, by setting the TV-1 (SVIDEO, Composite) device into DPMS mode or Full Power Down mode, and the ch7006 datasheet does say in this mode, all but the i2c circuits are disabled! Looking at

On Wed, Apr 2, 2014 at 5:24 PM, Roger <rogerx.oss at gmail.com> wrote: > After analyzing verbose nouveau & drm dmesg, I have found seemingly no more > useful details pertaining to having no TV-1 device. The TV-1 device might be > getting lost within DRM, by setting the TV-1 (SVIDEO, Composite) device into > DPMS mode or Full Power Down mode, and the ch7006 datasheet does say

On 01/26/2016 03:58 PM, Ilia Mirkin wrote: > On Tue, Jan 26, 2016 at 5:54 PM, don fisher <hdf3 at comcast.net> wrote: >> On 01/26/2016 03:24 PM, Ilia Mirkin wrote: >>> >>> sleep 1 && xset dpms force off >> >> Could you confirm exactly how to add the drm.debug=0x1e option. Is it >> another parameter on the kernel command line? > > Yep

https://bugs.freedesktop.org/show_bug.cgi?id=50830 Bug #: 50830 Summary: GeForce 8500 GT Connectors Reversed Classification: Unclassified Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component:

Hello, I am using a GTX660, NVE6 (GK106) on arch linux. kernel 3.16.3 xf86-video-nouveau 1.0.11 I am loading an EDID with kernel parameter drm_kms_helper.edid_firmware= DVI-I-1:edid/320x240.bin It doesn't apply the resolution. dmesg prints: [ 65.382880] [drm] Got external EDID base block and 0 extensions from "edid/320x240vesa.bin" for connector "DVI-I-1" [

This patch set nukes all the dummy crtc mode_fixup implementations. (made on top of Daniel topic/drm-misc branch) Signed-off-by: Carlos Palminha <palminha at synopsys.com> --- drivers/gpu/drm/gma500/cdv_intel_display.c | 13 ++++++------- drivers/gpu/drm/gma500/gma_display.c | 7 ------- drivers/gpu/drm/gma500/gma_display.h | 3 ---

> On Tue, Apr 01, 2014 at 02:53:02PM -0400, Ilia Mirkin wrote: >I believe that ch7006 is the only external encoder that's supposed to >work, so you're in luck. It sounds like it passes the nv04_tv_identify >stage of nv04_tv_create -- perhaps it fails later? Although based on >the prints, it's even doing dpms stuff (but it hits _detect a second >time... odd). Try

https://bugs.freedesktop.org/show_bug.cgi?id=51971 Bug #: 51971 Summary: MacBook Pro 10,1 Retina - Display Resets, No Connectors Classification: Unclassified Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium

While I had thought I'd tested this before, it looks like this one issue slipped by my original CRC patches. Basically, there seem to be a few rules we need to follow when sending CRC commands to the display controller: * CRCs cannot be both disabled and enabled for a single head in the same flush * If a head with CRC reporting enabled switches from one OR to another, there must be a

On 01/26/2016 03:24 PM, Ilia Mirkin wrote: > sleep 1 && xset dpms force off Could you confirm exactly how to add the drm.debug=0x1e option. Is it another parameter on the kernel command line? Where does the output data go? Is there a way to get it into a file? Thanks Don

- Use driver level (0x2) for NV_DEBUG instead of all levels - Create a NV_DEBUG_KMS for KMS level (04) and use them in modesetting code - Remove a few odd NV_TRACE calls and replace with NV_DEBUG_KMS Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bios.c | 12 +++++----- drivers/gpu/drm/nouveau/nouveau_connector.c | 8 +++---

Hi again, I got a new dmesg log with the debug parameters, but I guess I could not isolate VESA. I blacklisted it at /etc/modprobe.d/blacklist.conf but comparing those logs I see no difference... Is it possible to isolate VESA somehow without removing it? The new logs are here, I'm posting full content because I'm not sure what information is more relevant...

https://bugs.freedesktop.org/show_bug.cgi?id=103721 Bug ID: 103721 Summary: Frequent freezes with nouveau on Thinkpad P50 Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

*RESEND* due to exceeding the mailinglists limit for attachment size. Hi, I''m trying to get secondary vga-passthrough on a HVM guest to work with a AMD HD6570 and the native kernel radeon driver and kernel modesetting. So the guest still gets the emulated stdvga or cirrus device(used in my case here) as primary/boot vga adapter. - When i don''t passthrough the radeon card, the

https://bugs.freedesktop.org/show_bug.cgi?id=40747 Summary: The new nouveau kernel module fails to use my monitor's native resolution Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component:

This patch set nukes all the dummy crtc mode_fixup implementations. (made on top of Daniel topic/drm-misc branch) Carlos Palminha (16): drm: fixes crct set_mode when crtc mode_fixup is null. drm/cirrus: removed optional dummy crtc mode_fixup function. drm/mgag200: removed optional dummy crtc mode_fixup function. drm/udl: removed optional dummy crtc mode_fixup function. drm/gma: removed

This patch set nukes all the dummy crtc mode_fixup implementations. (made on top of Daniel topic/drm-misc branch) Carlos Palminha (16): drm: fixes crct set_mode when crtc mode_fixup is null. drm/cirrus: removed optional dummy crtc mode_fixup function. drm/mgag200: removed optional dummy crtc mode_fixup function. drm/udl: removed optional dummy crtc mode_fixup function. drm/gma: removed

It seems it was only locking up in the context of nouveau_hw_save_vga_fonts, when it actually did something (because the console wasn't already in graphics mode). Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_hw.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_hw.c

This patch series adds TV-out modesetting support to the KMS implementation. I've tried to test it on all the hardware I've got at hand (that is nv11, nv17, nv34, nv35, nv40, nv4b) with every possible output combination; I believe it has reached a mergeable state, however it depends on some commits from drm-next that haven't got into Linus' tree yet, if you agree to merge this

Hey, Are there any known issues with the Intel''s integrated HD graphics 4000? I just bought a new laptop and have tried everything I can think of to get Xen to load. After choosing Xen in GRUB, it just boots to a black screen. There is no error message , no dmesg output, nothing. I have no idea what is causing this problem. I''ve gotten Xen to install with no problems on another