[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #11 from Fabio Pedretti 2012-09-23 07:07:12 UTC --- (In reply to comment #10) > I can't reproduce this. Mesa master on RS880 is working fine here. A quick search in the git log returned this: http://cgit.freedesktop.org/mesa/mesa/commit/?id=7b4aefd3c9c1b04832306b8114b3f2007318f087 Did you compile with --enable-r600-llvm-compiler ? It's enabled in my PPA. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for LG SL80
Am Mittwoch, den 15.08.2012, 17:18 +0200 schrieb Paul Menzel:
> Date: Wed Aug 15 17:10:51 2012 +0200
>
> Connecting a LG SL80 [1] a garbled screen is shown with vertical stripes
> in the top half.
>
> In commit bc42aabc [2]
>
> commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
> Author: Adam Jackson
> Date: Wed May 23 16:26:54 2012 -0400
>
> drm/edid/quirks: ViewSonic VA2026w
>
> Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
> is also needed for this LG TV.
>
> All log files and output from `xrandr` is included in the referenced
> Bugzilla report #53544.
>
> [1] http://www.lg.com/de/tv-heimkino-blu-ray/tv/LG-lcd-tv-42SL8000.jsp
> [2]
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53544
> Signed-off-by: Paul Menzel
> Cc:
> Cc: Adam Jackson
> Cc: Ian Pilcher
> Cc:
> ---
> Same as in previous patch:
>
> Ian, I did not base this patch on your series, to make it easier to get
> back ported. I can easily rebase it though, so hopefully some maintainer
> can tell me what to do.
> ---
> drivers/gpu/drm/drm_edid.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index eb452e6..75e252e 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -94,6 +94,9 @@ static struct edid_quirk {
> /* Unknown Acer */
> { "ACR", 2423, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
>
> + /* LG SL80 */
> + { "GSM", 1, EDID_QUIRK_FORCE_REDUCED_BLANKING },
> +
> /* Belinea 10 15 55 */
> { "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
> { "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
Testing another TV (LG SL80), I had the same problems with, with a T60,
it worked fine [1]. Therefore the problems seems to be something else
and needs further investigation. Please do not commit this patch.
Thanks,
Paul
[3] https://bugs.freedesktop.org/show_bug.cgi?id=53544#c5
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26294] [Regression] Resolution for external TV/monitor Philips 32PFL5404H not set correctly
https://bugs.freedesktop.org/show_bug.cgi?id=26294 Paul Menzel changed: What|Removed |Added Summary|[Regression] Resolution for |[Regression] Resolution for |external monitor not set|external TV/monitor Philips |correctly |32PFL5404H not set ||correctly -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26294] [Regression] Resolution for external TV/monitor Philips 32PFL5404H not set correctly
https://bugs.freedesktop.org/show_bug.cgi?id=26294 --- Comment #25 from Paul Menzel --- (In reply to comment #23) > A similar patch as done in [1] > > commit bc42aabc6a01b92b0f961d65671564e0e1cd7592 > Author: Adam Jackson > Date: Wed May 23 16:26:54 2012 -0400 > > drm/edid/quirks: ViewSonic VA2026w > > Entirely new class of fail for this one. The detailed timings are for > normal CVT but the monitor really wanted CVT-R. > > Bugzilla: http://bugzilla.redhat/com/516471 > Signed-off-by: Adam Jackson > Signed-off-by: Dave Airlie > > is needed. > > I sent a patch to the dri-devel list [2]. > > It is strange though, that Windows despite using EDID according to Adam > Jackson supposedly gets this right, that means gets a working image on the > monitor. Testing another TV (LG SL80), I had the same problems with, with a Lenovo T60 instead of the ASUS EeePC 701 4G, it worked fine (bug 53544 comment 5) [3]. Therefore the problems seems to be something else and needs further investigation. Please do not commit this patch. > [1] > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592 > [2] http://lists.freedesktop.org/archives/dri-devel/2012-August/026469.html [3] https://bugs.freedesktop.org/show_bug.cgi?id=53544#c5 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53544] Incorrect modeline due to incorrect EDID block for LG SL80 TV
https://bugs.freedesktop.org/show_bug.cgi?id=53544 --- Comment #8 from Paul Menzel --- Comparing the modelines from the `xrandr -q --verbose` output they are the same, which is even more confusing. >From Lenovo T60. 1920x1080 (0xb9) 148.5MHz +HSync +VSync *current +preferred h: width 1920 start 2008 end 2052 total 2200 skew0 clock 67.5KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz >From ASUS EeePC 701 4G. The `*current` is missing, because when capturing it, I had to go back to LVDS, since it did not work by default. 1920x1080 (0xbd) 148.5MHz +HSync +VSync +preferred h: width 1920 start 2008 end 2052 total 2200 skew0 clock 67.5KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support
On 09/22/2012 03:17 AM, Sascha Hauer wrote: Hi Eric, On Fri, Sep 21, 2012 at 09:24:19AM -0700, Eric Nelson wrote: Hi Sascha, But ipu_crtc->imx_crtc gets initialized in this call, and ipu_irq_handler() makes use of it. The U-Boot code doesn't enable interrupts, so it's not acking along the way, and leaves bits set in IPU1_INT_STAT_15. I found that I can get around this in U-Boot by disabling the LCD controller and acking all of the interrupts after disabling the controller, but I haven't yet figured out where to tap into cleanup_before_linux(). Passing over an enabled IPU from the bootloader to the kernel is (currently) not a supported usecase, so U-Boot should indeed disable it. That said, the kernel driver should make sure the IPU is sufficiently configured before the interrupts are enabled, so this seems to be a bug that deserves fixing. Thanks Sascha, Patches for U-Boot are in process. http://lists.denx.de/pipermail/u-boot/2012-September/134807.html Regards, Eric ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] console: implement lockdep support for console_lock
On Sat, Sep 22, 2012 at 07:52:11PM +0200, Daniel Vetter wrote:
> Dave Airlie recently discovered a locking bug in the fbcon layer,
> where a timer_del_sync (for the blinking cursor) deadlocks with the
> timer itself, since both (want to) hold the console_lock:
>
> https://lkml.org/lkml/2012/8/21/36
>
> Unfortunately the console_lock isn't a plain mutex and hence has no
> lockdep support. Which resulted in a few days wasted of tracking down
> this bug (complicated by the fact that printk doesn't show anything
> when the console is locked) instead of noticing the bug much earlier
> with the lockdep splat.
>
> Hence I've figured I need to fix that for the next deadlock involving
> console_lock - and with kms/drm growing ever more complex locking
> that'll eventually happen.
>
> Now the console_lock has rather funky semantics, so after a quick irc
> discussion with Thomas Gleixner and Dave Airlie I've quickly ditched
> the original idead of switching to a real mutex (since it won't work)
> and instead opted to annotate the console_lock with lockdep
> information manually.
>
> There are a few special cases:
> - The console_lock state is protected by the console_sem, and usually
> grabbed/dropped at _lock/_unlock time. But the suspend/resume code
> drops the semaphore without dropping the console_lock (see
> suspend_console/resume_console). But since the same thread that did
> the suspend will do the resume, we don't need to fix up anything.
>
> - In the printk code there's a special trylock, only used to kick off
> the logbuffer printk'ing in console_unlock. But all that happens
> while lockdep is disable (since printk does a few other evil
> tricks). So no issue there, either.
>
> - The console_lock can also be acquired form irq context (but only
> with a trylock). lockdep already handles that.
>
> This all leaves us with annotating the normal console_lock, _unlock
> and _trylock functions.
>
> And yes, it works - simply unloading a drm kms driver resulted in
> lockdep complaining about the deadlock in fbcon_deinit:
>
> ==
> [ INFO: possible circular locking dependency detected ]
> 3.6.0-rc2+ #552 Not tainted
> ---
> kms-reload/3577 is trying to acquire lock:
> ((&info->queue)){+.+...}, at: [] wait_on_work+0x0/0xa7
>
> but task is already holding lock:
> (console_lock){+.+.+.}, at: [] bind_con_driver+0x38/0x263
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (console_lock){+.+.+.}:
>[] lock_acquire+0x95/0x105
>[] console_lock+0x59/0x5b
>[] fb_flashcursor+0x2e/0x12c
>[] process_one_work+0x1d9/0x3b4
>[] worker_thread+0x1a7/0x24b
>[] kthread+0x7f/0x87
>[] kernel_thread_helper+0x4/0x10
>
> -> #0 ((&info->queue)){+.+...}:
>[] __lock_acquire+0x999/0xcf6
>[] lock_acquire+0x95/0x105
>[] wait_on_work+0x3b/0xa7
>[] __cancel_work_timer+0xbf/0x102
>[] cancel_work_sync+0xb/0xd
>[] fbcon_deinit+0x11c/0x1dc
>[] bind_con_driver+0x145/0x263
>[] unbind_con_driver+0x14f/0x195
>[] store_bind+0x1ad/0x1c1
>[] dev_attr_store+0x13/0x1f
>[] sysfs_write_file+0xe9/0x121
>[] vfs_write+0x9b/0xfd
>[] sys_write+0x3e/0x6b
>[] system_call_fastpath+0x16/0x1b
>
> other info that might help us debug this:
>
> Possible unsafe locking scenario:
>
>CPU0CPU1
>
> lock(console_lock);
>lock((&info->queue));
>lock(console_lock);
> lock((&info->queue));
>
> *** DEADLOCK ***
>
> v2: Mark the lockdep_map static, noticed by Jani Nikula.
>
> Cc: Dave Airlie
> Cc: Thomas Gleixner
> Cc: Alan Cox
> Cc: Peter Zijlstra
> Signed-off-by: Daniel Vetter
> ---
> kernel/printk.c |9 +
> 1 file changed, 9 insertions(+)
So I'm guessing I should take this through the tty tree, right? Any
objections to that for 3.7?
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 0/4] Overview man-pages for libdrm
Hi This tries to continue the effort to document libdrm. I actually removed the X11-like man-page generation code as autotools now support man_MANS. The previous approach required every manpage to be in the same man-group. However, API calls belong in man3 and overview pages into man7. So I just use the simpler approach without all the replacements. It turns out, no man-page did use them so we can add it again if one really needs them. The other 3 patches add a generic drm.7 overview page, a drm-kms.7 overview page and a drm-memory.7 overview page. Also some aliases are installed, including drm-gem.7 => drm-memory.7 drm-ttm.7 => drm-memory.7 Please note that you cannot open the aliased pages with "man ./man/drm-gem.7". You must install them before they work correctly as they require the directory to be "man7" not "man". Anyway, any comments are welcome. This is really just something to start on and any corrections are appreciated. I have also added many dead-links to some other overview pages, including drm-prime.7: Short introduction to the PRIME API drm-intel.7, drm-radeon.7, drm-noueveau.7: Driver-dependent DRM API And many links to undocumented API calls. Feel free to write short stub-pages for any of them. It's better than nothing. I am also no groff/troff expert, but I think the pages look quite nice. And I recommend reading the pages with "man ./man/drm*.7" if you want to review them. Plain troff is really ugly to read. Regards David Some parts are copied from (I hope nobody minds?): http://lwn.net/Articles/283798/ http://lwn.net/Articles/499261/ David Herrmann (4): man: use automake man_MANS to allow multiple suffixes man: add man/drm.7 overview page man: add KMS overview page man: add drm-memory man-page man/Makefile.am | 22 +-- man/drm-gem.7 | 1 + man/drm-kms.7 | 269 + man/drm-memory.7| 412 man/drm-mm.7| 1 + man/drm-ttm.7 | 1 + man/drm.7 | 99 +++ man/drmAvailable.3 | 26 +++ man/drmAvailable.man| 25 --- man/drmHandleEvent.3| 48 ++ man/drmHandleEvent.man | 45 - man/drmModeGetResources.3 | 89 ++ man/drmModeGetResources.man | 79 - 13 files changed, 957 insertions(+), 160 deletions(-) create mode 100644 man/drm-gem.7 create mode 100644 man/drm-kms.7 create mode 100644 man/drm-memory.7 create mode 100644 man/drm-mm.7 create mode 100644 man/drm-ttm.7 create mode 100644 man/drm.7 create mode 100644 man/drmAvailable.3 delete mode 100644 man/drmAvailable.man create mode 100644 man/drmHandleEvent.3 delete mode 100644 man/drmHandleEvent.man create mode 100644 man/drmModeGetResources.3 delete mode 100644 man/drmModeGetResources.man -- 1.7.12.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 1/4] man: use automake man_MANS to allow multiple suffixes
Current man-page infrastructure supports only man3 but we wanto overview
files to be placed in man7. So use the new automake support for man_MANS
which installs the files automatically in the right location.
The current man-pages are simply moved and their header line is adjusted to the
new man-page headers.
Signed-off-by: David Herrmann
---
man/Makefile.am | 16 +++-
man/drmAvailable.3 | 26 +
man/drmAvailable.man| 25 -
man/drmHandleEvent.3| 48
man/drmHandleEvent.man | 45 ---
man/drmModeGetResources.3 | 89 +
man/drmModeGetResources.man | 79
7 files changed, 168 insertions(+), 160 deletions(-)
create mode 100644 man/drmAvailable.3
delete mode 100644 man/drmAvailable.man
create mode 100644 man/drmHandleEvent.3
delete mode 100644 man/drmHandleEvent.man
create mode 100644 man/drmModeGetResources.3
delete mode 100644 man/drmModeGetResources.man
diff --git a/man/Makefile.am b/man/Makefile.am
index 73068e6..f003101 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -1,11 +1,5 @@
-libmandir = $(LIB_MAN_DIR)
-libman_PRE = drmAvailable.man \
- drmHandleEvent.man \
- drmModeGetResources.man
-libman_DATA = $(libman_PRE:man=@LIB_MAN_SUFFIX@)
-EXTRA_DIST = $(libman_PRE)
-CLEANFILE = $(libman_DATA)
-SUFFIXES = .$(LIB_MAN_SUFFIX) .man
-
-.man.$(LIB_MAN_SUFFIX):
- $(AM_V_GEN)$(SED) $(MAN_SUBSTS) < $< > $@
+man_MANS = \
+ drmAvailable.3 \
+ drmHandleEvent.3 \
+ drmModeGetResources.3
+EXTRA_DIST = $(man_MANS)
diff --git a/man/drmAvailable.3 b/man/drmAvailable.3
new file mode 100644
index 000..d3abcf1
--- /dev/null
+++ b/man/drmAvailable.3
@@ -0,0 +1,26 @@
+.TH "drmAvailable" 3 "September 2012" "libdrm" "Direct Rendering Manager"
+.SH NAME
+drmAvailable \- determine whether a DRM kernel driver has been loaded
+
+.SH SYNOPSIS
+.nf
+.B "#include "
+
+.B "int drmAvailable(void);"
+.fi
+
+.SH DESCRIPTION
+This function allows the caller to determine whether a kernel DRM driver is
+loaded.
+
+.SH RETURN VALUE
+If a DRM driver is currently loaded, this function returns 1. Otherwise 0
+is returned.
+
+.SH REPORTING BUGS
+Bugs in this function should be reported to http://bugs.freedesktop.org under
+the "Mesa" product, with "Other" or "libdrm" as the component.
+
+.SH "SEE ALSO"
+.BR drm (7),
+.BR drmOpen (3)
diff --git a/man/drmAvailable.man b/man/drmAvailable.man
deleted file mode 100644
index e1bb8dc..000
--- a/man/drmAvailable.man
+++ /dev/null
@@ -1,25 +0,0 @@
-.\" shorthand for double quote that works everywhere.
-.ds q \N'34'
-.TH drmAvailable __drivermansuffix__ __vendorversion__
-.SH NAME
-drmAvailable \- determine whether a DRM kernel driver has been loaded
-.SH SYNOPSIS
-.nf
-.B "#include "
-
-.B "int drmAvailable(void);"
-.fi
-.SH DESCRIPTION
-This function allows the caller to determine whether a kernel DRM driver is
-loaded.
-
-.SH RETURN VALUE
-If a DRM driver is currently loaded, this function returns 1. Otherwise 0
-is returned.
-
-.SH REPORTING BUGS
-Bugs in this function should be reported to http://bugs.freedesktop.org under
-the "Mesa" product, with "Other" or "libdrm" as the component.
-
-.SH "SEE ALSO"
-drmOpen(__libmansuffix__)
diff --git a/man/drmHandleEvent.3 b/man/drmHandleEvent.3
new file mode 100644
index 000..bc933ed
--- /dev/null
+++ b/man/drmHandleEvent.3
@@ -0,0 +1,48 @@
+.TH "drmHandleEvent" 3 "September 2012" "libdrm" "Direct Rendering Manager"
+.SH NAME
+drmHandleEvent \- read and process pending DRM events
+
+.SH SYNOPSIS
+.nf
+.B "#include "
+
+.B "typedef struct _drmEventContext {"
+.BI " int version;"
+.BI " void (*vblank_handler)(int fd,"
+.BI " unsigned int sequence,"
+.BI " unsigned int tv_sec,"
+.BI " unsigned int tv_usec,"
+.BI " void *user_data);"
+.BI " void (*page_flip_handler)(int fd,"
+.BI "unsigned int sequence,"
+.BI "unsigned int tv_sec,"
+.BI "unsigned int tv_usec,"
+.BI "void *user_data);"
+.B "} drmEventContext, *drmEventContextPtr;"
+
+.B "int drmHandleEvent(int fd, drmEventContextPtr evctx);"
+.fi
+
+.SH DESCRIPTION
+This function will process outstanding DRM events on
+.I fd
+, which must be an open DRM device. This function should be called after
+the DRM file descriptor has polled readable; it will read the events and
+use the passed-in
+.I evctx
+structure to call function pointers with the parameters noted above.
+
+.SH RETURN VALUE
+Returns 0 on success, or if there is no data to read from the file descriptor.
+Returns -1 if the read on the file descriptor fails or returns less than a
+full event record.
+
+.SH REPORTING BUGS
+Bugs in this function should be reported to http://bugs.freedesktop.o
[PATCH libdrm 2/4] man: add man/drm.7 overview page
This man-page is supposed to provide an overview of the whole DRM system. It is targeted to users that have never worked with DRM and forwards the reader to the correct other man-pages. Detailed information on each system are available in separate man-pages which are currently under construction. Signed-off-by: David Herrmann --- man/Makefile.am | 1 + man/drm.7 | 99 + 2 files changed, 100 insertions(+) create mode 100644 man/drm.7 diff --git a/man/Makefile.am b/man/Makefile.am index f003101..6193a95 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -1,4 +1,5 @@ man_MANS = \ + drm.7 \ drmAvailable.3 \ drmHandleEvent.3 \ drmModeGetResources.3 diff --git a/man/drm.7 b/man/drm.7 new file mode 100644 index 000..d8d6f38 --- /dev/null +++ b/man/drm.7 @@ -0,0 +1,99 @@ +.\" +.\" Written 2012 by David Herrmann +.\" Dedicated to the Public Domain +.\" +.TH "DRM" 7 "September 2012" "libdrm" "Direct Rendering Manager" +.SH NAME +DRM \- Direct Rendering Manager + +.SH SYNOPSIS +.B #include + +.SH DESCRIPTION +The +.B Direct Rendering Manager +(DRM) is a framework to manage +.B Graphics Processing Units +(GPUs). It is designed to support the needs of complex graphics devices, usually +containing programmable pipelines well suited to 3D graphics acceleration. +Furthermore, it is responsible for memory management, interrupt handling and DMA +to provide a uniform interface to applications. + +In earlier days, the kernel framework was solely used to provide raw hardware +access to priviledged user-space processes which implement all the hardware +abstraction layers. But more and more tasks where moved into the kernel. All +these interfaces are based on +.BR ioctl (2) +commands on the DRM character device. The +.B libdrm +library provides wrappers for these system-calls and many helpers to simplify +the API. + +When a GPU is detected, the DRM system loads a driver for the detected hardware +type. Each connected GPU is then presented to user-space via a character-device +that is usually available as +.I /dev/dri/card0 +and can be accessed with +.BR open (2) +and +.BR close (2). +However, it still depends on the grapics driver which interfaces are available +on these devices. If an interface is not available, the syscalls will fail with +EINVAL. + +.SS Authentication +All DRM devices provide authentication mechanisms. Only a DRM-Master is allowed +to perform mode-setting or modify core state and only one user can be DRM-Master +at a time. See +.BR drmSetMaster (3) +for information on how to become DRM-Master and what the limitations are. +Other DRM users can be authenticated to the DRM-Master via +.BR drmAuthMagic (3) +so they can perform buffer allocations and rendering. + +.SS Mode-Setting +Managing connected monitors and displays and changing the current modes is +called +.BR Mode-Setting . +This is restricted to the current DRM-Master. Historically, this was implemented +in user-space, but new DRM drivers implement a kernel interface to perform +mode-setting called +.B Kernel Mode Setting +(KMS). If your hardware-driver supports it, you can use the KMS API provided by +DRM. This includes allocating framebuffers, selecting modes and managing CRTCs +and encoders. See +.BR drm-kms (7) +for more. + +.SS Memory Management +The most sophisticated tasks for GPUs today is managing memory objects. +Textures, framebuffers, command-buffers and all other kinds of commands for the +GPU have to be stored in memory. The DRM driver takes care of managing all +memory objects, flushing caches, synchronizing access and providing CPU access +to GPU memory. +.br +All memory management is hardware driver dependent. However, two generic +frameworks are available that are used by most DRM drivers. These are the +.B Translation Table Manager +(TTM) and the +.B Graphics Execution Manager +(GEM). They provide generic APIs to create, destroy and access buffers from +user-space. However, there are still many differences between the drivers so +driver-depedent code is still needed. Many helpers are provided in +.B libgbm +(Graphics Buffer Manager) from the +.IR mesa-project . +For more information on DRM memory-management, see +.BR drm-memory (7). + +.SH REPORTING BUGS +Bugs in this manual should be reported to http://bugs.freedesktop.org under +the "Mesa" product, with "Other" or "libdrm" as the component. + +.SH "SEE ALSO" +.BR drm-kms (7), +.BR drm-memory (7), +.BR drmSetMaster (3), +.BR drmAuthMagic (3), +.BR drmAvailable (3), +.BR drmOpen (3) -- 1.7.12.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 3/4] man: add KMS overview page
drm-kms.7 is an overview page which contains basic information on kernel mode-setting. It is targeted to users that are not familiar with DRM internals and gives short examples how basic mode-setting can be performed. It introduces the main vocabulary including CRTCs, encoders, connectors, framebuffers, planes and cursors. Signed-off-by: David Herrmann --- man/Makefile.am | 1 + man/drm-kms.7 | 269 2 files changed, 270 insertions(+) create mode 100644 man/drm-kms.7 diff --git a/man/Makefile.am b/man/Makefile.am index 6193a95..7ce7ac4 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -1,5 +1,6 @@ man_MANS = \ drm.7 \ + drm-kms.7 \ drmAvailable.3 \ drmHandleEvent.3 \ drmModeGetResources.3 diff --git a/man/drm-kms.7 b/man/drm-kms.7 new file mode 100644 index 000..38838bf --- /dev/null +++ b/man/drm-kms.7 @@ -0,0 +1,269 @@ +.\" +.\" Written 2012 by David Herrmann +.\" Dedicated to the Public Domain +.\" +.TH "DRM-KMS" 7 "September 2012" "libdrm" "Direct Rendering Manager" +.SH NAME +DRM-KMS \- Kernel Mode-Setting + +.SH SYNOPSIS +.B #include +.br +.B #include + +.SH DESCRIPTION +Each DRM device provides access to manage which monitors and displays are +currently used and what frames to be displayed. This task is called +.BR "Kernel Mode-Setting " (KMS). +Historically, this was done in user-space and called +.BR "User-space Mode-Setting " (UMS). +Almost all open-source drivers now provide the KMS kernel API to do this in the +kernel, however, many non-open-source binary drivers from different vendors +still do not support this. You can use +.BR drmModeSettingSupported (3) +to check whether your driver supports this. +.br +To understand how KMS works, we need to introduce 5 objects: +.IR CRTCs ", " Planes ", " Encoders ", " Connectors " and " Framebuffers + +.IP "\fBCRTCs\fP" +A +.BR CRTC , +short for +.B CRT Controller +is an abstraction representing a part of the chip that contains a pointer to a +scanout buffer. Therefore, the number of CRTCs available determines how many +independent scanout buffers can be active at any given time. The CRTC structure +contains several fields to support this: a pointer to some video memory +(abstracted as a frame-buffer object), a list of driven connectors, a display +mode and an (x, y) offset into the video memory to support panning or +configurations where one piece of video memory spans multiple CRTCs. +.br +A CRTC is the central point where configuration of displays happens. You select +which objects to use, which modes and which parameters and then configure each +CRTC via +.BR drmModeCrtcSet (3) +to drive the display devices. + +.IP "\fBPlanes\fP" +A +.B plane +respresents an image source that can be blended with or overlayed on top of a +CRTC during the scanout process. Planes are associated with a frame-buffer to +crop a portion of the image memory (source) and optionally scale it to a +destination size. The result is then blended with or overlayed on top of a CRTC. +.br +Planes are not provided by all hardware and the number of available planes is +limited. If planes are not available or if not enough planes are available, the +user should fall back to normal software blending (via GPU or CPU). + +.IP "\fBEncoders\fP" +An +.B encoder +takes pixel data from a CRTC and converts it to a format suitable for any +attached connectors. On some devices, it may be possible to have a CRTC send +data to more than one encoder. In that case, both encoders would receive data +from the same scanout buffer, resulting in a +.I cloned +display configuration across the connectors attached to each encoder. + +.IP "\fBConnectors\fP" +A +.B connector +is the final destination of pixel-data on a device, and usually connects +directly to an external display device like a monitor or laptop panel. A +connector can only be attached to one encoder at a time. The connector is also +the structure where information about the attached display is kept, so it +contains fields for display data, +.IR EDID " data, " DPMS " and " "connection status" , +and information about modes supported on the attached displays. + +.IP "\fBFramebuffers\fP" +.B Framebuffers +are abstract memory objects that provide a source of pixel data to scanout to a +CRTC. Applications explicitely request the creation of framebuffers and can +control their behavior. +.br +Framebuffers rely on the underneath memory manager for low-level memory +operations. When creating a framebuffer, applications pass a memory handle +through the API which is used as backing storage. The framebuffer itself is only +an abstract object with no data. It just refers to memory buffers that must be +created with the +.BR drm-memory (7) +API. + +.SS Mode-Setting +Before mode-setting can be performed, an application needs to call +.BR drmSetMaster (3) +to become +.IR DRM-Master "." +It then has exclusive access to the KMS API. A call to +.B
[PATCH libdrm 4/4] man: add drm-memory man-page
The drm-memory man-page (aliased as drm-gem, drm-mm and drm-ttm) describes
the high-level overview of different memory-management frameworks used in
the DRM subsystem. It is really targeted at driver-independent semantics
(and where it applies, syntax). It links to all other man-pages if more
driver-dependent information is needed.
Signed-off-by: David Herrmann
---
man/Makefile.am | 4 +
man/drm-gem.7| 1 +
man/drm-memory.7 | 412 +++
man/drm-mm.7 | 1 +
man/drm-ttm.7| 1 +
5 files changed, 419 insertions(+)
create mode 100644 man/drm-gem.7
create mode 100644 man/drm-memory.7
create mode 100644 man/drm-mm.7
create mode 100644 man/drm-ttm.7
diff --git a/man/Makefile.am b/man/Makefile.am
index 7ce7ac4..ded3b4a 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -1,6 +1,10 @@
man_MANS = \
drm.7 \
drm-kms.7 \
+ drm-memory.7 \
+ drm-mm.7 \
+ drm-gem.7 \
+ drm-ttm.7 \
drmAvailable.3 \
drmHandleEvent.3 \
drmModeGetResources.3
diff --git a/man/drm-gem.7 b/man/drm-gem.7
new file mode 100644
index 000..258b5a3
--- /dev/null
+++ b/man/drm-gem.7
@@ -0,0 +1 @@
+.so man7/drm-memory.7
diff --git a/man/drm-memory.7 b/man/drm-memory.7
new file mode 100644
index 000..1eff38a
--- /dev/null
+++ b/man/drm-memory.7
@@ -0,0 +1,412 @@
+.\"
+.\" Written 2012 by David Herrmann
+.\" Dedicated to the Public Domain
+.\"
+.TH "DRM-MEMORY" 7 "September 2012" "libdrm" "Direct Rendering Manager"
+.SH NAME
+DRM-Memory \- DRM Memory Management
+
+.SH SYNOPSIS
+.B #include
+
+.SH DESCRIPTION
+Many modern high-end GPUs come with their own memory managers. They even
include
+several different caches that need to be synchronized during access. Textures,
+framebuffers, command buffers and more need to be stored in memory that can be
+accessed quickly by the GPU. Therefore, memory management on GPUs is highly
+driver\- and hardware\-dependent.
+
+However, there are several frameworks in the kernel that are used by more than
+one driver. These can be used for trivial mode-setting without requiring
+driver-dependent code. But for hardware-accelerated rendering you need to read
+the manual pages for the driver you want to work with.
+
+.SS Dumb-Buffers
+Almost all in-kernel DRM hardware drivers support an API called
+.BR "Dumb-Buffers" "."
+This API allows to create buffers of arbitrary size that can be used for
+scanout. These buffers can be memory mapped via
+.BR mmap (2)
+so you can render into them on the CPU. However, GPU access to these buffers is
+often not possible. Therefore, they are fine for simple tasks but not suitable
+for complex compositions and renderings.
+
+The
+.B DRM_IOCTL_MODE_CREATE_DUMB
+ioctl can be used to create a dumb buffer. The kernel will return a 32bit
handle
+that can be used to manage the buffer with the DRM API. You can create
+framebuffers with
+.BR drmModeAddFB (3)
+and use it for mode-setting and scanout.
+.br
+To access the buffer, you first need to retrieve the offset of the buffer. The
+.B DRM_IOCTL_MODE_MAP_DUMB
+ioctl requests the DRM subsystem to prepare the buffer for memory-mapping and
+returns a fake-offset that can be used with
+.BR mmap "(2)."
+
+The
+.B DRM_IOCTL_MODE_CREATE_DUMB
+ioctl takes as argument a structure of type
+.IR "struct drm_mode_create_dumb" :
+
+.in +4n
+.nf
+struct drm_mode_create_dumb {
+ __u32 height;
+ __u32 width;
+ __u32 bpp;
+ __u32 flags;
+
+ __u32 handle;
+ __u32 pitch;
+ __u64 size;
+};
+.fi
+.in
+
+The fields
+.IR "height" ", " "width" ", " "bpp" " and " "flags"
+have to be provided by the caller. The other fields are filled by the kernel
+with the return values.
+.IR "height" " and " "width"
+are the dimensions of the rectangular buffer that is created.
+.I "bpp"
+is the number of bits-per-pixel and must be a multiple of
+.IR 8 "."
+You most commonly want to pass
+.I 32
+here. The
+.I "flags"
+field is currently unused and must be zeroed. Different flags to modify the
+behavior may be added in the future.
+.br
+After calling the ioctl, the
+.IR "handle" ", " "pitch" " and " "size"
+fields are filled by the kernel.
+.I "handle"
+is a 32bit gem handle that identifies the buffer. This is used by several other
+calls that take a gem-handle or memory-buffer as argument. The
+.I "pitch"
+field is the
+.IR pitch " or " stride
+of the new buffer. Most drivers use 32bit or 64bit aligned stride-values. The
+.I "size"
+field contains the absolute size in bytes of the buffer. This can normally also
+be computed with
+"(height * pitch + width) * bpp / 4".
+
+To prepare the buffer for
+.BR mmap (2)
+you need to use the
+.B DRM_IOCTL_MODE_MAP_DUMB
+ioctl. It takes as argument a structure of type
+.IR "struct drm_mode_map_dumb" :
+
+.in +4n
+.nf
+struct drm_mode_map_dumb {
+ __u32 handle;
+ __u32 pad;
+
+ __u64 offset;
+};
+.fi
+.in
+
+You need to put the gem-handle that
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #12 from kowalski marcin --- i'm currently experiencing this with rs780 and darkplaces. I only get black screen, and logs are filled with this error. I have an llvm-enabled build of mesa. This is on current git @ fb40f88338b6af23faae03ced5906add8507db26 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #13 from Michael Lange --- (In reply to comment #9) > > E.g., LD_LIBRARY_PATH= > LIBGL_DRIVERS_PATH= glxgears > > will run glxgears with your new Mesa. thanks, this works currently bisecting mesa - two steps to go -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #14 from Tom Stellard --- If you are using the llvm compiler setting the environment variable R600_LLVM=0 will cause the driver to fall back to the TGSI compiler and should fix the rendering errors. It would be helpful if someone could run one of the affected programs with the R600_DUMP_SHADES=1 environment variable set and post the output. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #15 from Tom Stellard --- (In reply to comment #14) > If you are using the llvm compiler setting the environment variable > R600_LLVM=0 will cause the driver to fall back to the TGSI compiler and > should fix the rendering errors. > > It would be helpful if someone could run one of the affected programs with > the R600_DUMP_SHADES=1 environment variable set and post the output. Sorry, typo above. The environment variable is R600_DUMP_SHADERS=1 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for Philips 32PFL5404H
Am Mittwoch, den 15.08.2012, 16:31 +0200 schrieb Paul Menzel:
> Date: Wed, 8 Aug 2012 23:12:19 +0200
>
> < ajax> i would preface this whole discussion with the observation that all
> tvs are garbage
>
> Connecting the Philips 32PFL5404H [1] a garbled screen is shown with
> vertical stripes in the top half.
>
> As written in the referenced Bugzilla #26294 report I am pretty sure
> this worked sometime before 2010. My guess is that EDID beforehand was
> interpreted incorrectly – as probably MS Windows does – which made it
> work.
>
> In commit bc42aabc [2]
>
> commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
> Author: Adam Jackson
> Date: Wed May 23 16:26:54 2012 -0400
>
> drm/edid/quirks: ViewSonic VA2026w
>
> Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
> is also needed for this Philips TV.
>
> The problem is that the Model number is set to zero. I hope this will
> not break other Philips TVs out there.
>
> All log files and output from `xrandr` is included in the referenced
> Bugzilla report #26294.
>
> [1]
> http://www.p4c.philips.com/cgi-bin/dcbint/cpindex.pl?ctn=32PFL5404H/12&scy=DE&slg=de
> [2]
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=26294
> Tested-by: Paul Menzel
> (ASUS Eee PC 701 4G with Debian Sid/unstable connected over VGA)
> Signed-off-by: Paul Menzel
> Cc:
> Cc: Adam Jackson
> Cc: Ian Pilcher
> Cc:
> ---
> Ian, I did not base this patch on your series, to make it easier to get
> back ported. I can easily rebase it though, so hopefully some maintainer
> can tell me what to do.
>
> I also do not know if URLs in the quirk comments are considered useful
> or not.
> ---
> drivers/gpu/drm/drm_edid.c |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a8743c3..eb452e6 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -111,6 +111,11 @@ static struct edid_quirk {
> { "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
> { "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
>
> + /* Philips 32PFL5404H TV */
> + /*
> http://www.p4c.philips.com/cgi-bin/dcbint/cpindex.pl?ctn=32PFL5404H/12&scy=DE&slg=de
> */
> + /* https://bugs.freedesktop.org/show_bug.cgi?id=26294 */
> + { "PHL", 0, EDID_QUIRK_FORCE_REDUCED_BLANKING },
> +
> /* Philips 107p5 CRT */
> { "PHL", 57364, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
Testing another TV (LG SL80), I had had the same problems with, with a
Lenovo T60, it worked fine without the patch [1]. Therefore the problems
seems to be something else and needs further investigation. Please do
not commit this patch.
Thanks,
Paul
[3] https://bugs.freedesktop.org/show_bug.cgi?id=53544#c5
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #16 from Michael Lange --- bisecting mesa comes to this 0e0c21e00ee80bcff67e37ec86b97d6c25db066a is the first bad commit commit 0e0c21e00ee80bcff67e37ec86b97d6c25db066a Author: Michal Sciubidlo Date: Wed Sep 12 08:57:01 2012 +0200 radeon/llvm: Emit ISA for ALU instructions in the R600 code emitter Signed-off-by: Tom Stellard :04 04 de615a99537b02f3e978f285393559da27d8c1da 2e75e2c1ba7912acfdbbb38c65c3c21831b258da Msrc configure is in comment 7 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #17 from Michael Lange --- Created attachment 67582 --> https://bugs.freedesktop.org/attachment.cgi?id=67582&action=edit R600_DUMP_SHADERS=1 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 Michael Lange changed: What|Removed |Added Attachment #67582|0 |1 is obsolete|| --- Comment #18 from Michael Lange --- Created attachment 67583 --> https://bugs.freedesktop.org/attachment.cgi?id=67583&action=edit R600_DUMP_SHADERS=1 ahhh ... rtf-file - i hate this texteditor from macosx nano make this right ;) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #19 from Michael Lange --- in case it is important, i have set some environment variables belly@jelly ~/mesa $ env | grep R600 R600_STREAMOUT=1 R600_HYPERZ=1 R600_GLSL130=1 R600_TILING=1 R600_SURF=1 this was set for a few months to test something, i forgot to reset this -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #20 from Tom Stellard --- Created attachment 67586 --> https://bugs.freedesktop.org/attachment.cgi?id=67586&action=edit Possible fix Does this patch fix the problem? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53544] Incorrect modeline due to incorrect EDID block for LG SL80 TV
https://bugs.freedesktop.org/show_bug.cgi?id=53544 --- Comment #9 from Paul Menzel --- To be clear, both systems use the same Linux kernel and userspace (Debian Sid/unstable). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
On 08/23/2012 09:55 AM, Kukjin Kim wrote: > Florian Tobias Schandinat wrote: >> >> On 08/01/2012 02:28 AM, Kukjin Kim wrote: >>> Leela Krishna Amudala wrote: This patchset moves the contents of regs-fb-v4.h and regs-fb.h from >> arch side to include/video/samsung_fimd.h This patchset is created and rebased against master branch of torvalds tree. Tested on smdk5250 board, build tested for other boards. >>> (Cc'ed Florian Tobias Schandinat) >>> >>> Yeah, since it's merge window, this series could be created against on >>> mainline. And IMO, would be helpful to us if this series could be sent >> to >>> upstream via samsung tree after reviewing, because this touches too many >>> files in samsung tree and just adds include/video/samsung_fimd.h. But >> I'm >>> not sure the added inclusion will be used in other file of > drivers/video. >> If >>> so, I can provide some topic branch can be merged into Florian's tree. >>> Florian, how about? >> >> Using a topic branch to merge it in both trees sounds like a good plan >> to me. >> > Florian, > > Please pull following topic branch we talked. I already merged it into my > -next. > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > v3.7-for-florian > > Note, I applied Leela's V4 patches not this V2 series. Merged, just as I wrote in another thread. Took a bit longer as I was writing my thesis... Best regards, Florian Tobias Schandinat > > If any problems, please kindly let me know. > > Thanks. > > Best regards, > Kgene. > -- > Kukjin Kim , Senior Engineer, > SW Solution Development Team, Samsung Electronics Co., Ltd. > > The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: > > Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) > > are available in the git repository at: > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > v3.7-for-florian > > Leela Krishna Amudala (2): > include/video: move fimd register headers from platform to > include/video > include/video: Add register offsets for FIMD version 8 > > arch/arm/mach-exynos/mach-nuri.c |2 +- > arch/arm/mach-exynos/mach-origen.c |2 +- > arch/arm/mach-exynos/mach-smdk4x12.c |2 +- > arch/arm/mach-exynos/mach-smdkv310.c |2 +- > arch/arm/mach-exynos/mach-universal_c210.c |2 +- > arch/arm/mach-exynos/setup-fimd0.c |2 +- > arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- > arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- > arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- > arch/arm/mach-s3c64xx/mach-hmt.c |2 +- > arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- > arch/arm/mach-s3c64xx/mach-ncp.c |2 +- > arch/arm/mach-s3c64xx/mach-real6410.c |2 +- > arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- > arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- > arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- > arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- > arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- > arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- > arch/arm/mach-s5pv210/mach-aquila.c|2 +- > arch/arm/mach-s5pv210/mach-goni.c |2 +- > arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- > arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 > > drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- > drivers/video/s3c-fb.c |2 +- > .../plat/regs-fb.h => include/video/samsung_fimd.h | 152 > +-- > 26 files changed, 165 insertions(+), 194 deletions(-) > delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > rename arch/arm/plat-samsung/include/plat/regs-fb.h => > include/video/samsung_fimd.h (73%) > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #21 from Michael Lange --- (In reply to comment #20) > Created attachment 67586 [details] [review] > Possible fix > > Does this patch fix the problem? your patch works tested with the latest mesa-version from git -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55256] New: r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256
Priority: medium
Bug ID: 55256
Assignee: dri-devel@lists.freedesktop.org
Summary: r600g R600_LLVM=1 bad rendering (light blue instead of
grey)
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: edwin+m...@etorok.net
Hardware: Other
Status: NEW
Version: git
Component: Drivers/DRI/R600
Product: Mesa
Created attachment 67592
--> https://bugs.freedesktop.org/attachment.cgi?id=67592&action=edit
apitrace
Attached is an apitrace, and screenshots.
Bad behaviour with --enable-r600-llvm-compiler:
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV730
OpenGL version string: 3.0 Mesa 9.1-devel (git-fb40f88)
OpenGL shading language version string: 1.30
If you look at the 'bad.png' screenshot you'll see that the 4th column is light
blue. It should be grey.
With R600_LLVM=0 the good behaviour is seen: good.png.
See the apitrace for the full shader, here is the relevant bit:
else if (gl_FragCoord.x < 640)
color = vec4(1.0f, 1.0f, 1.0f, 1.0f);//white
[...]
vec4 color0, color1, color2, color3;
if (gl_FragCoord.y < 200) {
color0 = color1 = color2 = color;//75%
[...]
} else if (xmod < 55 || xmod >= 105 ||
ymod < 75 || ymod >= 125) {
// real color
// TODO: buggy on r600g with LLVM?
gl_FragColor = (color0 + color1 + color2 + color3) / 4.0f;
P.S.: the shader is not optimal, most of the branches could be moved out of it,
I haven't tried to minimize the testcase though.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 --- Comment #1 from Török Edwin --- Created attachment 67593 --> https://bugs.freedesktop.org/attachment.cgi?id=67593&action=edit another.trace Another apitrace that doesn't use 3.0 features and can thus be replayed with LIBGL_ALWAYS_SOFTWARE too. The software rendered shows the same (good) behaviour as the R600_LLVM=0. Note: the color values have a different gamma in this trace. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 --- Comment #2 from Török Edwin --- Created attachment 67594 --> https://bugs.freedesktop.org/attachment.cgi?id=67594&action=edit bad.png -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 --- Comment #3 from Török Edwin --- Created attachment 67595 --> https://bugs.freedesktop.org/attachment.cgi?id=67595&action=edit good.png -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 --- Comment #4 from Török Edwin --- Graphics card type: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV730 PRO [Radeon HD 4650] xorg.conf: Section "Device" Identifier "Radeon" Driver "radeon" Option "ColorTiling2D" "True" BusID "PCI:1:0:0" EndSection kernel: Linux debian 3.6.0-rc6 x86_64 Mesa build flags: ./configure --prefix=/opt/xorg --with-driver=dri --with-state-trackers="egl dri" --with-dri-drivers=i965 --with-gallium-drivers="r600 swrast" LLVM_CONFIG=/usr/bin/llvm-config-3.1 --enable-r600-llvm-compiler --enable-openvg --enable-vdpau --enable-glx-tls --enable-shared-glapi --enable-texture-float --enable-egl --enable-gallium-egl --enable-gbm --enable-gallium-gbm --with-egl-platforms=x11,drm,fbdev --enable-gles2 /opt/xorg has xserver, drm, libkms, etc. from git. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 Török Edwin changed: What|Removed |Added Attachment #67594|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 Török Edwin changed: What|Removed |Added Attachment #67595|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 Török Edwin changed: What|Removed |Added Attachment #67593|text/plain |application/octet-stream mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 Török Edwin changed: What|Removed |Added Attachment #67592|text/plain |application/octet-stream mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 Török Edwin changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) CC||tstel...@gmail.com Component|Drivers/DRI/R600|Drivers/Gallium/r600 --- Comment #5 from Török Edwin --- Sorry, chose wrong component: bug is about r600g. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch] vmwgfx: corruption in vmw_event_fence_action_create()
We don't allocate enough data for this struct. As soon as we start
modifying event->event on the next lines, then we're going beyond the
end of the memory we allocated.
Signed-off-by: Dan Carpenter
---
Static checker work. Not tested.
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index f2fb8f1..7e07433 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -1018,7 +1018,7 @@ int vmw_event_fence_action_create(struct drm_file
*file_priv,
}
- event = kzalloc(sizeof(event->event), GFP_KERNEL);
+ event = kzalloc(sizeof(*event), GFP_KERNEL);
if (unlikely(event == NULL)) {
DRM_ERROR("Failed to allocate an event.\n");
ret = -ENOMEM;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #11 from Fabio Pedretti 2012-09-23 07:07:12 UTC --- (In reply to comment #10) > I can't reproduce this. Mesa master on RS880 is working fine here. A quick search in the git log returned this: http://cgit.freedesktop.org/mesa/mesa/commit/?id=7b4aefd3c9c1b04832306b8114b3f2007318f087 Did you compile with --enable-r600-llvm-compiler ? It's enabled in my PPA. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for LG SL80
Am Mittwoch, den 15.08.2012, 17:18 +0200 schrieb Paul Menzel:
> Date: Wed Aug 15 17:10:51 2012 +0200
>
> Connecting a LG SL80 [1] a garbled screen is shown with vertical stripes
> in the top half.
>
> In commit bc42aabc [2]
>
> commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
> Author: Adam Jackson
> Date: Wed May 23 16:26:54 2012 -0400
>
> drm/edid/quirks: ViewSonic VA2026w
>
> Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
> is also needed for this LG TV.
>
> All log files and output from `xrandr` is included in the referenced
> Bugzilla report #53544.
>
> [1] http://www.lg.com/de/tv-heimkino-blu-ray/tv/LG-lcd-tv-42SL8000.jsp
> [2]
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53544
> Signed-off-by: Paul Menzel
> Cc:
> Cc: Adam Jackson
> Cc: Ian Pilcher
> Cc:
> ---
> Same as in previous patch:
>
> Ian, I did not base this patch on your series, to make it easier to get
> back ported. I can easily rebase it though, so hopefully some maintainer
> can tell me what to do.
> ---
> drivers/gpu/drm/drm_edid.c |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index eb452e6..75e252e 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -94,6 +94,9 @@ static struct edid_quirk {
> /* Unknown Acer */
> { "ACR", 2423, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
>
> + /* LG SL80 */
> + { "GSM", 1, EDID_QUIRK_FORCE_REDUCED_BLANKING },
> +
> /* Belinea 10 15 55 */
> { "MAX", 1516, EDID_QUIRK_PREFER_LARGE_60 },
> { "MAX", 0x77e, EDID_QUIRK_PREFER_LARGE_60 },
Testing another TV (LG SL80), I had the same problems with, with a T60,
it worked fine [1]. Therefore the problems seems to be something else
and needs further investigation. Please do not commit this patch.
Thanks,
Paul
[3] https://bugs.freedesktop.org/show_bug.cgi?id=53544#c5
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/cd31faa4/attachment.pgp>
[Bug 26294] [Regression] Resolution for external TV/monitor Philips 32PFL5404H not set correctly
https://bugs.freedesktop.org/show_bug.cgi?id=26294 Paul Menzel changed: What|Removed |Added Summary|[Regression] Resolution for |[Regression] Resolution for |external monitor not set|external TV/monitor Philips |correctly |32PFL5404H not set ||correctly -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/6049605b/attachment-0001.html>
[Bug 26294] [Regression] Resolution for external TV/monitor Philips 32PFL5404H not set correctly
https://bugs.freedesktop.org/show_bug.cgi?id=26294 --- Comment #25 from Paul Menzel --- (In reply to comment #23) > A similar patch as done in [1] > > commit bc42aabc6a01b92b0f961d65671564e0e1cd7592 > Author: Adam Jackson > Date: Wed May 23 16:26:54 2012 -0400 > > drm/edid/quirks: ViewSonic VA2026w > > Entirely new class of fail for this one. The detailed timings are for > normal CVT but the monitor really wanted CVT-R. > > Bugzilla: http://bugzilla.redhat/com/516471 > Signed-off-by: Adam Jackson > Signed-off-by: Dave Airlie > > is needed. > > I sent a patch to the dri-devel list [2]. > > It is strange though, that Windows despite using EDID according to Adam > Jackson supposedly gets this right, that means gets a working image on the > monitor. Testing another TV (LG SL80), I had the same problems with, with a Lenovo T60 instead of the ASUS EeePC 701 4G, it worked fine (bug 53544 comment 5) [3]. Therefore the problems seems to be something else and needs further investigation. Please do not commit this patch. > [1] > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592 > [2] http://lists.freedesktop.org/archives/dri-devel/2012-August/026469.html [3] https://bugs.freedesktop.org/show_bug.cgi?id=53544#c5 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/286b3cd7/attachment.html>
[Bug 53544] Incorrect modeline due to incorrect EDID block for LG SL80 TV
https://bugs.freedesktop.org/show_bug.cgi?id=53544 --- Comment #8 from Paul Menzel --- Comparing the modelines from the `xrandr -q --verbose` output they are the same, which is even more confusing. >From Lenovo T60. 1920x1080 (0xb9) 148.5MHz +HSync +VSync *current +preferred h: width 1920 start 2008 end 2052 total 2200 skew0 clock 67.5KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz >From ASUS EeePC 701 4G. The `*current` is missing, because when capturing it, I had to go back to LVDS, since it did not work by default. 1920x1080 (0xbd) 148.5MHz +HSync +VSync +preferred h: width 1920 start 2008 end 2052 total 2200 skew0 clock 67.5KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/48d31a02/attachment.html>
[PATCH libdrm 0/4] Overview man-pages for libdrm
Hi This tries to continue the effort to document libdrm. I actually removed the X11-like man-page generation code as autotools now support man_MANS. The previous approach required every manpage to be in the same man-group. However, API calls belong in man3 and overview pages into man7. So I just use the simpler approach without all the replacements. It turns out, no man-page did use them so we can add it again if one really needs them. The other 3 patches add a generic drm.7 overview page, a drm-kms.7 overview page and a drm-memory.7 overview page. Also some aliases are installed, including drm-gem.7 => drm-memory.7 drm-ttm.7 => drm-memory.7 Please note that you cannot open the aliased pages with "man ./man/drm-gem.7". You must install them before they work correctly as they require the directory to be "man7" not "man". Anyway, any comments are welcome. This is really just something to start on and any corrections are appreciated. I have also added many dead-links to some other overview pages, including drm-prime.7: Short introduction to the PRIME API drm-intel.7, drm-radeon.7, drm-noueveau.7: Driver-dependent DRM API And many links to undocumented API calls. Feel free to write short stub-pages for any of them. It's better than nothing. I am also no groff/troff expert, but I think the pages look quite nice. And I recommend reading the pages with "man ./man/drm*.7" if you want to review them. Plain troff is really ugly to read. Regards David Some parts are copied from (I hope nobody minds?): http://lwn.net/Articles/283798/ http://lwn.net/Articles/499261/ David Herrmann (4): man: use automake man_MANS to allow multiple suffixes man: add man/drm.7 overview page man: add KMS overview page man: add drm-memory man-page man/Makefile.am | 22 +-- man/drm-gem.7 | 1 + man/drm-kms.7 | 269 + man/drm-memory.7| 412 man/drm-mm.7| 1 + man/drm-ttm.7 | 1 + man/drm.7 | 99 +++ man/drmAvailable.3 | 26 +++ man/drmAvailable.man| 25 --- man/drmHandleEvent.3| 48 ++ man/drmHandleEvent.man | 45 - man/drmModeGetResources.3 | 89 ++ man/drmModeGetResources.man | 79 - 13 files changed, 957 insertions(+), 160 deletions(-) create mode 100644 man/drm-gem.7 create mode 100644 man/drm-kms.7 create mode 100644 man/drm-memory.7 create mode 100644 man/drm-mm.7 create mode 100644 man/drm-ttm.7 create mode 100644 man/drm.7 create mode 100644 man/drmAvailable.3 delete mode 100644 man/drmAvailable.man create mode 100644 man/drmHandleEvent.3 delete mode 100644 man/drmHandleEvent.man create mode 100644 man/drmModeGetResources.3 delete mode 100644 man/drmModeGetResources.man -- 1.7.12.1
[PATCH libdrm 1/4] man: use automake man_MANS to allow multiple suffixes
Current man-page infrastructure supports only man3 but we wanto overview
files to be placed in man7. So use the new automake support for man_MANS
which installs the files automatically in the right location.
The current man-pages are simply moved and their header line is adjusted to the
new man-page headers.
Signed-off-by: David Herrmann
---
man/Makefile.am | 16 +++-
man/drmAvailable.3 | 26 +
man/drmAvailable.man| 25 -
man/drmHandleEvent.3| 48
man/drmHandleEvent.man | 45 ---
man/drmModeGetResources.3 | 89 +
man/drmModeGetResources.man | 79
7 files changed, 168 insertions(+), 160 deletions(-)
create mode 100644 man/drmAvailable.3
delete mode 100644 man/drmAvailable.man
create mode 100644 man/drmHandleEvent.3
delete mode 100644 man/drmHandleEvent.man
create mode 100644 man/drmModeGetResources.3
delete mode 100644 man/drmModeGetResources.man
diff --git a/man/Makefile.am b/man/Makefile.am
index 73068e6..f003101 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -1,11 +1,5 @@
-libmandir = $(LIB_MAN_DIR)
-libman_PRE = drmAvailable.man \
- drmHandleEvent.man \
- drmModeGetResources.man
-libman_DATA = $(libman_PRE:man=@LIB_MAN_SUFFIX@)
-EXTRA_DIST = $(libman_PRE)
-CLEANFILE = $(libman_DATA)
-SUFFIXES = .$(LIB_MAN_SUFFIX) .man
-
-.man.$(LIB_MAN_SUFFIX):
- $(AM_V_GEN)$(SED) $(MAN_SUBSTS) < $< > $@
+man_MANS = \
+ drmAvailable.3 \
+ drmHandleEvent.3 \
+ drmModeGetResources.3
+EXTRA_DIST = $(man_MANS)
diff --git a/man/drmAvailable.3 b/man/drmAvailable.3
new file mode 100644
index 000..d3abcf1
--- /dev/null
+++ b/man/drmAvailable.3
@@ -0,0 +1,26 @@
+.TH "drmAvailable" 3 "September 2012" "libdrm" "Direct Rendering Manager"
+.SH NAME
+drmAvailable \- determine whether a DRM kernel driver has been loaded
+
+.SH SYNOPSIS
+.nf
+.B "#include "
+
+.B "int drmAvailable(void);"
+.fi
+
+.SH DESCRIPTION
+This function allows the caller to determine whether a kernel DRM driver is
+loaded.
+
+.SH RETURN VALUE
+If a DRM driver is currently loaded, this function returns 1. Otherwise 0
+is returned.
+
+.SH REPORTING BUGS
+Bugs in this function should be reported to http://bugs.freedesktop.org under
+the "Mesa" product, with "Other" or "libdrm" as the component.
+
+.SH "SEE ALSO"
+.BR drm (7),
+.BR drmOpen (3)
diff --git a/man/drmAvailable.man b/man/drmAvailable.man
deleted file mode 100644
index e1bb8dc..000
--- a/man/drmAvailable.man
+++ /dev/null
@@ -1,25 +0,0 @@
-.\" shorthand for double quote that works everywhere.
-.ds q \N'34'
-.TH drmAvailable __drivermansuffix__ __vendorversion__
-.SH NAME
-drmAvailable \- determine whether a DRM kernel driver has been loaded
-.SH SYNOPSIS
-.nf
-.B "#include "
-
-.B "int drmAvailable(void);"
-.fi
-.SH DESCRIPTION
-This function allows the caller to determine whether a kernel DRM driver is
-loaded.
-
-.SH RETURN VALUE
-If a DRM driver is currently loaded, this function returns 1. Otherwise 0
-is returned.
-
-.SH REPORTING BUGS
-Bugs in this function should be reported to http://bugs.freedesktop.org under
-the "Mesa" product, with "Other" or "libdrm" as the component.
-
-.SH "SEE ALSO"
-drmOpen(__libmansuffix__)
diff --git a/man/drmHandleEvent.3 b/man/drmHandleEvent.3
new file mode 100644
index 000..bc933ed
--- /dev/null
+++ b/man/drmHandleEvent.3
@@ -0,0 +1,48 @@
+.TH "drmHandleEvent" 3 "September 2012" "libdrm" "Direct Rendering Manager"
+.SH NAME
+drmHandleEvent \- read and process pending DRM events
+
+.SH SYNOPSIS
+.nf
+.B "#include "
+
+.B "typedef struct _drmEventContext {"
+.BI " int version;"
+.BI " void (*vblank_handler)(int fd,"
+.BI " unsigned int sequence,"
+.BI " unsigned int tv_sec,"
+.BI " unsigned int tv_usec,"
+.BI " void *user_data);"
+.BI " void (*page_flip_handler)(int fd,"
+.BI "unsigned int sequence,"
+.BI "unsigned int tv_sec,"
+.BI "unsigned int tv_usec,"
+.BI "void *user_data);"
+.B "} drmEventContext, *drmEventContextPtr;"
+
+.B "int drmHandleEvent(int fd, drmEventContextPtr evctx);"
+.fi
+
+.SH DESCRIPTION
+This function will process outstanding DRM events on
+.I fd
+, which must be an open DRM device. This function should be called after
+the DRM file descriptor has polled readable; it will read the events and
+use the passed-in
+.I evctx
+structure to call function pointers with the parameters noted above.
+
+.SH RETURN VALUE
+Returns 0 on success, or if there is no data to read from the file descriptor.
+Returns -1 if the read on the file descriptor fails or returns less than a
+full event record.
+
+.SH REPORTING BUGS
+Bugs in this function should be reported to http://bugs.freedesktop.o
[PATCH libdrm 2/4] man: add man/drm.7 overview page
This man-page is supposed to provide an overview of the whole DRM system. It is targeted to users that have never worked with DRM and forwards the reader to the correct other man-pages. Detailed information on each system are available in separate man-pages which are currently under construction. Signed-off-by: David Herrmann --- man/Makefile.am | 1 + man/drm.7 | 99 + 2 files changed, 100 insertions(+) create mode 100644 man/drm.7 diff --git a/man/Makefile.am b/man/Makefile.am index f003101..6193a95 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -1,4 +1,5 @@ man_MANS = \ + drm.7 \ drmAvailable.3 \ drmHandleEvent.3 \ drmModeGetResources.3 diff --git a/man/drm.7 b/man/drm.7 new file mode 100644 index 000..d8d6f38 --- /dev/null +++ b/man/drm.7 @@ -0,0 +1,99 @@ +.\" +.\" Written 2012 by David Herrmann +.\" Dedicated to the Public Domain +.\" +.TH "DRM" 7 "September 2012" "libdrm" "Direct Rendering Manager" +.SH NAME +DRM \- Direct Rendering Manager + +.SH SYNOPSIS +.B #include + +.SH DESCRIPTION +The +.B Direct Rendering Manager +(DRM) is a framework to manage +.B Graphics Processing Units +(GPUs). It is designed to support the needs of complex graphics devices, usually +containing programmable pipelines well suited to 3D graphics acceleration. +Furthermore, it is responsible for memory management, interrupt handling and DMA +to provide a uniform interface to applications. + +In earlier days, the kernel framework was solely used to provide raw hardware +access to priviledged user-space processes which implement all the hardware +abstraction layers. But more and more tasks where moved into the kernel. All +these interfaces are based on +.BR ioctl (2) +commands on the DRM character device. The +.B libdrm +library provides wrappers for these system-calls and many helpers to simplify +the API. + +When a GPU is detected, the DRM system loads a driver for the detected hardware +type. Each connected GPU is then presented to user-space via a character-device +that is usually available as +.I /dev/dri/card0 +and can be accessed with +.BR open (2) +and +.BR close (2). +However, it still depends on the grapics driver which interfaces are available +on these devices. If an interface is not available, the syscalls will fail with +EINVAL. + +.SS Authentication +All DRM devices provide authentication mechanisms. Only a DRM-Master is allowed +to perform mode-setting or modify core state and only one user can be DRM-Master +at a time. See +.BR drmSetMaster (3) +for information on how to become DRM-Master and what the limitations are. +Other DRM users can be authenticated to the DRM-Master via +.BR drmAuthMagic (3) +so they can perform buffer allocations and rendering. + +.SS Mode-Setting +Managing connected monitors and displays and changing the current modes is +called +.BR Mode-Setting . +This is restricted to the current DRM-Master. Historically, this was implemented +in user-space, but new DRM drivers implement a kernel interface to perform +mode-setting called +.B Kernel Mode Setting +(KMS). If your hardware-driver supports it, you can use the KMS API provided by +DRM. This includes allocating framebuffers, selecting modes and managing CRTCs +and encoders. See +.BR drm-kms (7) +for more. + +.SS Memory Management +The most sophisticated tasks for GPUs today is managing memory objects. +Textures, framebuffers, command-buffers and all other kinds of commands for the +GPU have to be stored in memory. The DRM driver takes care of managing all +memory objects, flushing caches, synchronizing access and providing CPU access +to GPU memory. +.br +All memory management is hardware driver dependent. However, two generic +frameworks are available that are used by most DRM drivers. These are the +.B Translation Table Manager +(TTM) and the +.B Graphics Execution Manager +(GEM). They provide generic APIs to create, destroy and access buffers from +user-space. However, there are still many differences between the drivers so +driver-depedent code is still needed. Many helpers are provided in +.B libgbm +(Graphics Buffer Manager) from the +.IR mesa-project . +For more information on DRM memory-management, see +.BR drm-memory (7). + +.SH REPORTING BUGS +Bugs in this manual should be reported to http://bugs.freedesktop.org under +the "Mesa" product, with "Other" or "libdrm" as the component. + +.SH "SEE ALSO" +.BR drm-kms (7), +.BR drm-memory (7), +.BR drmSetMaster (3), +.BR drmAuthMagic (3), +.BR drmAvailable (3), +.BR drmOpen (3) -- 1.7.12.1
[PATCH libdrm 3/4] man: add KMS overview page
drm-kms.7 is an overview page which contains basic information on kernel mode-setting. It is targeted to users that are not familiar with DRM internals and gives short examples how basic mode-setting can be performed. It introduces the main vocabulary including CRTCs, encoders, connectors, framebuffers, planes and cursors. Signed-off-by: David Herrmann --- man/Makefile.am | 1 + man/drm-kms.7 | 269 2 files changed, 270 insertions(+) create mode 100644 man/drm-kms.7 diff --git a/man/Makefile.am b/man/Makefile.am index 6193a95..7ce7ac4 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -1,5 +1,6 @@ man_MANS = \ drm.7 \ + drm-kms.7 \ drmAvailable.3 \ drmHandleEvent.3 \ drmModeGetResources.3 diff --git a/man/drm-kms.7 b/man/drm-kms.7 new file mode 100644 index 000..38838bf --- /dev/null +++ b/man/drm-kms.7 @@ -0,0 +1,269 @@ +.\" +.\" Written 2012 by David Herrmann +.\" Dedicated to the Public Domain +.\" +.TH "DRM-KMS" 7 "September 2012" "libdrm" "Direct Rendering Manager" +.SH NAME +DRM-KMS \- Kernel Mode-Setting + +.SH SYNOPSIS +.B #include +.br +.B #include + +.SH DESCRIPTION +Each DRM device provides access to manage which monitors and displays are +currently used and what frames to be displayed. This task is called +.BR "Kernel Mode-Setting " (KMS). +Historically, this was done in user-space and called +.BR "User-space Mode-Setting " (UMS). +Almost all open-source drivers now provide the KMS kernel API to do this in the +kernel, however, many non-open-source binary drivers from different vendors +still do not support this. You can use +.BR drmModeSettingSupported (3) +to check whether your driver supports this. +.br +To understand how KMS works, we need to introduce 5 objects: +.IR CRTCs ", " Planes ", " Encoders ", " Connectors " and " Framebuffers + +.IP "\fBCRTCs\fP" +A +.BR CRTC , +short for +.B CRT Controller +is an abstraction representing a part of the chip that contains a pointer to a +scanout buffer. Therefore, the number of CRTCs available determines how many +independent scanout buffers can be active at any given time. The CRTC structure +contains several fields to support this: a pointer to some video memory +(abstracted as a frame-buffer object), a list of driven connectors, a display +mode and an (x, y) offset into the video memory to support panning or +configurations where one piece of video memory spans multiple CRTCs. +.br +A CRTC is the central point where configuration of displays happens. You select +which objects to use, which modes and which parameters and then configure each +CRTC via +.BR drmModeCrtcSet (3) +to drive the display devices. + +.IP "\fBPlanes\fP" +A +.B plane +respresents an image source that can be blended with or overlayed on top of a +CRTC during the scanout process. Planes are associated with a frame-buffer to +crop a portion of the image memory (source) and optionally scale it to a +destination size. The result is then blended with or overlayed on top of a CRTC. +.br +Planes are not provided by all hardware and the number of available planes is +limited. If planes are not available or if not enough planes are available, the +user should fall back to normal software blending (via GPU or CPU). + +.IP "\fBEncoders\fP" +An +.B encoder +takes pixel data from a CRTC and converts it to a format suitable for any +attached connectors. On some devices, it may be possible to have a CRTC send +data to more than one encoder. In that case, both encoders would receive data +from the same scanout buffer, resulting in a +.I cloned +display configuration across the connectors attached to each encoder. + +.IP "\fBConnectors\fP" +A +.B connector +is the final destination of pixel-data on a device, and usually connects +directly to an external display device like a monitor or laptop panel. A +connector can only be attached to one encoder at a time. The connector is also +the structure where information about the attached display is kept, so it +contains fields for display data, +.IR EDID " data, " DPMS " and " "connection status" , +and information about modes supported on the attached displays. + +.IP "\fBFramebuffers\fP" +.B Framebuffers +are abstract memory objects that provide a source of pixel data to scanout to a +CRTC. Applications explicitely request the creation of framebuffers and can +control their behavior. +.br +Framebuffers rely on the underneath memory manager for low-level memory +operations. When creating a framebuffer, applications pass a memory handle +through the API which is used as backing storage. The framebuffer itself is only +an abstract object with no data. It just refers to memory buffers that must be +created with the +.BR drm-memory (7) +API. + +.SS Mode-Setting +Before mode-setting can be performed, an application needs to call +.BR drmSetMaster (3) +to become +.IR DRM-Master "." +It then has exclusive access to the KMS API. A call to +.B
[PATCH libdrm 4/4] man: add drm-memory man-page
The drm-memory man-page (aliased as drm-gem, drm-mm and drm-ttm) describes
the high-level overview of different memory-management frameworks used in
the DRM subsystem. It is really targeted at driver-independent semantics
(and where it applies, syntax). It links to all other man-pages if more
driver-dependent information is needed.
Signed-off-by: David Herrmann
---
man/Makefile.am | 4 +
man/drm-gem.7| 1 +
man/drm-memory.7 | 412 +++
man/drm-mm.7 | 1 +
man/drm-ttm.7| 1 +
5 files changed, 419 insertions(+)
create mode 100644 man/drm-gem.7
create mode 100644 man/drm-memory.7
create mode 100644 man/drm-mm.7
create mode 100644 man/drm-ttm.7
diff --git a/man/Makefile.am b/man/Makefile.am
index 7ce7ac4..ded3b4a 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -1,6 +1,10 @@
man_MANS = \
drm.7 \
drm-kms.7 \
+ drm-memory.7 \
+ drm-mm.7 \
+ drm-gem.7 \
+ drm-ttm.7 \
drmAvailable.3 \
drmHandleEvent.3 \
drmModeGetResources.3
diff --git a/man/drm-gem.7 b/man/drm-gem.7
new file mode 100644
index 000..258b5a3
--- /dev/null
+++ b/man/drm-gem.7
@@ -0,0 +1 @@
+.so man7/drm-memory.7
diff --git a/man/drm-memory.7 b/man/drm-memory.7
new file mode 100644
index 000..1eff38a
--- /dev/null
+++ b/man/drm-memory.7
@@ -0,0 +1,412 @@
+.\"
+.\" Written 2012 by David Herrmann
+.\" Dedicated to the Public Domain
+.\"
+.TH "DRM-MEMORY" 7 "September 2012" "libdrm" "Direct Rendering Manager"
+.SH NAME
+DRM-Memory \- DRM Memory Management
+
+.SH SYNOPSIS
+.B #include
+
+.SH DESCRIPTION
+Many modern high-end GPUs come with their own memory managers. They even
include
+several different caches that need to be synchronized during access. Textures,
+framebuffers, command buffers and more need to be stored in memory that can be
+accessed quickly by the GPU. Therefore, memory management on GPUs is highly
+driver\- and hardware\-dependent.
+
+However, there are several frameworks in the kernel that are used by more than
+one driver. These can be used for trivial mode-setting without requiring
+driver-dependent code. But for hardware-accelerated rendering you need to read
+the manual pages for the driver you want to work with.
+
+.SS Dumb-Buffers
+Almost all in-kernel DRM hardware drivers support an API called
+.BR "Dumb-Buffers" "."
+This API allows to create buffers of arbitrary size that can be used for
+scanout. These buffers can be memory mapped via
+.BR mmap (2)
+so you can render into them on the CPU. However, GPU access to these buffers is
+often not possible. Therefore, they are fine for simple tasks but not suitable
+for complex compositions and renderings.
+
+The
+.B DRM_IOCTL_MODE_CREATE_DUMB
+ioctl can be used to create a dumb buffer. The kernel will return a 32bit
handle
+that can be used to manage the buffer with the DRM API. You can create
+framebuffers with
+.BR drmModeAddFB (3)
+and use it for mode-setting and scanout.
+.br
+To access the buffer, you first need to retrieve the offset of the buffer. The
+.B DRM_IOCTL_MODE_MAP_DUMB
+ioctl requests the DRM subsystem to prepare the buffer for memory-mapping and
+returns a fake-offset that can be used with
+.BR mmap "(2)."
+
+The
+.B DRM_IOCTL_MODE_CREATE_DUMB
+ioctl takes as argument a structure of type
+.IR "struct drm_mode_create_dumb" :
+
+.in +4n
+.nf
+struct drm_mode_create_dumb {
+ __u32 height;
+ __u32 width;
+ __u32 bpp;
+ __u32 flags;
+
+ __u32 handle;
+ __u32 pitch;
+ __u64 size;
+};
+.fi
+.in
+
+The fields
+.IR "height" ", " "width" ", " "bpp" " and " "flags"
+have to be provided by the caller. The other fields are filled by the kernel
+with the return values.
+.IR "height" " and " "width"
+are the dimensions of the rectangular buffer that is created.
+.I "bpp"
+is the number of bits-per-pixel and must be a multiple of
+.IR 8 "."
+You most commonly want to pass
+.I 32
+here. The
+.I "flags"
+field is currently unused and must be zeroed. Different flags to modify the
+behavior may be added in the future.
+.br
+After calling the ioctl, the
+.IR "handle" ", " "pitch" " and " "size"
+fields are filled by the kernel.
+.I "handle"
+is a 32bit gem handle that identifies the buffer. This is used by several other
+calls that take a gem-handle or memory-buffer as argument. The
+.I "pitch"
+field is the
+.IR pitch " or " stride
+of the new buffer. Most drivers use 32bit or 64bit aligned stride-values. The
+.I "size"
+field contains the absolute size in bytes of the buffer. This can normally also
+be computed with
+"(height * pitch + width) * bpp / 4".
+
+To prepare the buffer for
+.BR mmap (2)
+you need to use the
+.B DRM_IOCTL_MODE_MAP_DUMB
+ioctl. It takes as argument a structure of type
+.IR "struct drm_mode_map_dumb" :
+
+.in +4n
+.nf
+struct drm_mode_map_dumb {
+ __u32 handle;
+ __u32 pad;
+
+ __u64 offset;
+};
+.fi
+.in
+
+You need to put the gem-handle that
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #12 from kowalski marcin --- i'm currently experiencing this with rs780 and darkplaces. I only get black screen, and logs are filled with this error. I have an llvm-enabled build of mesa. This is on current git @ fb40f88338b6af23faae03ced5906add8507db26 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/0e9aa9b4/attachment.html>
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #13 from Michael Lange --- (In reply to comment #9) > > E.g., LD_LIBRARY_PATH= > LIBGL_DRIVERS_PATH= glxgears > > will run glxgears with your new Mesa. thanks, this works currently bisecting mesa - two steps to go -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/9ac9863b/attachment.html>
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #14 from Tom Stellard --- If you are using the llvm compiler setting the environment variable R600_LLVM=0 will cause the driver to fall back to the TGSI compiler and should fix the rendering errors. It would be helpful if someone could run one of the affected programs with the R600_DUMP_SHADES=1 environment variable set and post the output. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/b60877b3/attachment.html>
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #15 from Tom Stellard --- (In reply to comment #14) > If you are using the llvm compiler setting the environment variable > R600_LLVM=0 will cause the driver to fall back to the TGSI compiler and > should fix the rendering errors. > > It would be helpful if someone could run one of the affected programs with > the R600_DUMP_SHADES=1 environment variable set and post the output. Sorry, typo above. The environment variable is R600_DUMP_SHADERS=1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/5a7cbf4a/attachment.html>
[PATCH] drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for Philips 32PFL5404H
Am Mittwoch, den 15.08.2012, 16:31 +0200 schrieb Paul Menzel:
> Date: Wed, 8 Aug 2012 23:12:19 +0200
>
> < ajax> i would preface this whole discussion with the observation that all
> tvs are garbage
>
> Connecting the Philips 32PFL5404H [1] a garbled screen is shown with
> vertical stripes in the top half.
>
> As written in the referenced Bugzilla #26294 report I am pretty sure
> this worked sometime before 2010. My guess is that EDID beforehand was
> interpreted incorrectly ? as probably MS Windows does ? which made it
> work.
>
> In commit bc42aabc [2]
>
> commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
> Author: Adam Jackson
> Date: Wed May 23 16:26:54 2012 -0400
>
> drm/edid/quirks: ViewSonic VA2026w
>
> Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
> is also needed for this Philips TV.
>
> The problem is that the Model number is set to zero. I hope this will
> not break other Philips TVs out there.
>
> All log files and output from `xrandr` is included in the referenced
> Bugzilla report #26294.
>
> [1]
> http://www.p4c.philips.com/cgi-bin/dcbint/cpindex.pl?ctn=32PFL5404H/12&scy=DE&slg=de
> [2]
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=26294
> Tested-by: Paul Menzel
> (ASUS Eee PC 701 4G with Debian Sid/unstable connected over VGA)
> Signed-off-by: Paul Menzel
> Cc:
> Cc: Adam Jackson
> Cc: Ian Pilcher
> Cc:
> ---
> Ian, I did not base this patch on your series, to make it easier to get
> back ported. I can easily rebase it though, so hopefully some maintainer
> can tell me what to do.
>
> I also do not know if URLs in the quirk comments are considered useful
> or not.
> ---
> drivers/gpu/drm/drm_edid.c |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a8743c3..eb452e6 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -111,6 +111,11 @@ static struct edid_quirk {
> { "LPL", 0, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
> { "LPL", 0x2a00, EDID_QUIRK_DETAILED_USE_MAXIMUM_SIZE },
>
> + /* Philips 32PFL5404H TV */
> + /*
> http://www.p4c.philips.com/cgi-bin/dcbint/cpindex.pl?ctn=32PFL5404H/12&scy=DE&slg=de
> */
> + /* https://bugs.freedesktop.org/show_bug.cgi?id=26294 */
> + { "PHL", 0, EDID_QUIRK_FORCE_REDUCED_BLANKING },
> +
> /* Philips 107p5 CRT */
> { "PHL", 57364, EDID_QUIRK_FIRST_DETAILED_PREFERRED },
Testing another TV (LG SL80), I had had the same problems with, with a
Lenovo T60, it worked fine without the patch [1]. Therefore the problems
seems to be something else and needs further investigation. Please do
not commit this patch.
Thanks,
Paul
[3] https://bugs.freedesktop.org/show_bug.cgi?id=53544#c5
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/c37def54/attachment.pgp>
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #16 from Michael Lange --- bisecting mesa comes to this 0e0c21e00ee80bcff67e37ec86b97d6c25db066a is the first bad commit commit 0e0c21e00ee80bcff67e37ec86b97d6c25db066a Author: Michal Sciubidlo Date: Wed Sep 12 08:57:01 2012 +0200 radeon/llvm: Emit ISA for ALU instructions in the R600 code emitter Signed-off-by: Tom Stellard :04 04 de615a99537b02f3e978f285393559da27d8c1da 2e75e2c1ba7912acfdbbb38c65c3c21831b258da Msrc configure is in comment 7 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/ad7a4ad9/attachment.html>
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #17 from Michael Lange --- Created attachment 67582 --> https://bugs.freedesktop.org/attachment.cgi?id=67582&action=edit R600_DUMP_SHADERS=1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/4025c341/attachment-0001.html>
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 Michael Lange changed: What|Removed |Added Attachment #67582|0 |1 is obsolete|| --- Comment #18 from Michael Lange --- Created attachment 67583 --> https://bugs.freedesktop.org/attachment.cgi?id=67583&action=edit R600_DUMP_SHADERS=1 ahhh ... rtf-file - i hate this texteditor from macosx nano make this right ;) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/40cd418e/attachment.html>
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #19 from Michael Lange --- in case it is important, i have set some environment variables belly at jelly ~/mesa $ env | grep R600 R600_STREAMOUT=1 R600_HYPERZ=1 R600_GLSL130=1 R600_TILING=1 R600_SURF=1 this was set for a few months to test something, i forgot to reset this -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/a7a9b206/attachment.html>
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #20 from Tom Stellard --- Created attachment 67586 --> https://bugs.freedesktop.org/attachment.cgi?id=67586&action=edit Possible fix Does this patch fix the problem? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/219fd6c8/attachment.html>
[Bug 53544] Incorrect modeline due to incorrect EDID block for LG SL80 TV
https://bugs.freedesktop.org/show_bug.cgi?id=53544 --- Comment #9 from Paul Menzel --- To be clear, both systems use the same Linux kernel and userspace (Debian Sid/unstable). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/6fb74b59/attachment.html>
[PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
On 08/23/2012 09:55 AM, Kukjin Kim wrote: > Florian Tobias Schandinat wrote: >> >> On 08/01/2012 02:28 AM, Kukjin Kim wrote: >>> Leela Krishna Amudala wrote: This patchset moves the contents of regs-fb-v4.h and regs-fb.h from >> arch side to include/video/samsung_fimd.h This patchset is created and rebased against master branch of torvalds tree. Tested on smdk5250 board, build tested for other boards. >>> (Cc'ed Florian Tobias Schandinat) >>> >>> Yeah, since it's merge window, this series could be created against on >>> mainline. And IMO, would be helpful to us if this series could be sent >> to >>> upstream via samsung tree after reviewing, because this touches too many >>> files in samsung tree and just adds include/video/samsung_fimd.h. But >> I'm >>> not sure the added inclusion will be used in other file of > drivers/video. >> If >>> so, I can provide some topic branch can be merged into Florian's tree. >>> Florian, how about? >> >> Using a topic branch to merge it in both trees sounds like a good plan >> to me. >> > Florian, > > Please pull following topic branch we talked. I already merged it into my > -next. > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > v3.7-for-florian > > Note, I applied Leela's V4 patches not this V2 series. Merged, just as I wrote in another thread. Took a bit longer as I was writing my thesis... Best regards, Florian Tobias Schandinat > > If any problems, please kindly let me know. > > Thanks. > > Best regards, > Kgene. > -- > Kukjin Kim , Senior Engineer, > SW Solution Development Team, Samsung Electronics Co., Ltd. > > The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: > > Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) > > are available in the git repository at: > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > v3.7-for-florian > > Leela Krishna Amudala (2): > include/video: move fimd register headers from platform to > include/video > include/video: Add register offsets for FIMD version 8 > > arch/arm/mach-exynos/mach-nuri.c |2 +- > arch/arm/mach-exynos/mach-origen.c |2 +- > arch/arm/mach-exynos/mach-smdk4x12.c |2 +- > arch/arm/mach-exynos/mach-smdkv310.c |2 +- > arch/arm/mach-exynos/mach-universal_c210.c |2 +- > arch/arm/mach-exynos/setup-fimd0.c |2 +- > arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- > arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- > arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- > arch/arm/mach-s3c64xx/mach-hmt.c |2 +- > arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- > arch/arm/mach-s3c64xx/mach-ncp.c |2 +- > arch/arm/mach-s3c64xx/mach-real6410.c |2 +- > arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- > arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- > arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- > arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- > arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- > arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- > arch/arm/mach-s5pv210/mach-aquila.c|2 +- > arch/arm/mach-s5pv210/mach-goni.c |2 +- > arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- > arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 > > drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- > drivers/video/s3c-fb.c |2 +- > .../plat/regs-fb.h => include/video/samsung_fimd.h | 152 > +-- > 26 files changed, 165 insertions(+), 194 deletions(-) > delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > rename arch/arm/plat-samsung/include/plat/regs-fb.h => > include/video/samsung_fimd.h (73%) > >
[Bug 55217] [RS880] opengl not working anymore
https://bugs.freedesktop.org/show_bug.cgi?id=55217 --- Comment #21 from Michael Lange --- (In reply to comment #20) > Created attachment 67586 [details] [review] > Possible fix > > Does this patch fix the problem? your patch works tested with the latest mesa-version from git -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/4b08f0e4/attachment.html>
[Bug 55256] New: r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256
Priority: medium
Bug ID: 55256
Assignee: dri-devel at lists.freedesktop.org
Summary: r600g R600_LLVM=1 bad rendering (light blue instead of
grey)
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: edwin+mesa at etorok.net
Hardware: Other
Status: NEW
Version: git
Component: Drivers/DRI/R600
Product: Mesa
Created attachment 67592
--> https://bugs.freedesktop.org/attachment.cgi?id=67592&action=edit
apitrace
Attached is an apitrace, and screenshots.
Bad behaviour with --enable-r600-llvm-compiler:
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV730
OpenGL version string: 3.0 Mesa 9.1-devel (git-fb40f88)
OpenGL shading language version string: 1.30
If you look at the 'bad.png' screenshot you'll see that the 4th column is light
blue. It should be grey.
With R600_LLVM=0 the good behaviour is seen: good.png.
See the apitrace for the full shader, here is the relevant bit:
else if (gl_FragCoord.x < 640)
color = vec4(1.0f, 1.0f, 1.0f, 1.0f);//white
[...]
vec4 color0, color1, color2, color3;
if (gl_FragCoord.y < 200) {
color0 = color1 = color2 = color;//75%
[...]
} else if (xmod < 55 || xmod >= 105 ||
ymod < 75 || ymod >= 125) {
// real color
// TODO: buggy on r600g with LLVM?
gl_FragColor = (color0 + color1 + color2 + color3) / 4.0f;
P.S.: the shader is not optimal, most of the branches could be moved out of it,
I haven't tried to minimize the testcase though.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/fa5dc16a/attachment.html>
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 --- Comment #1 from T?r?k Edwin --- Created attachment 67593 --> https://bugs.freedesktop.org/attachment.cgi?id=67593&action=edit another.trace Another apitrace that doesn't use 3.0 features and can thus be replayed with LIBGL_ALWAYS_SOFTWARE too. The software rendered shows the same (good) behaviour as the R600_LLVM=0. Note: the color values have a different gamma in this trace. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/e36ae9f0/attachment.html>
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 --- Comment #2 from T?r?k Edwin --- Created attachment 67594 --> https://bugs.freedesktop.org/attachment.cgi?id=67594&action=edit bad.png -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/0d85b516/attachment.html>
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 --- Comment #3 from T?r?k Edwin --- Created attachment 67595 --> https://bugs.freedesktop.org/attachment.cgi?id=67595&action=edit good.png -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/94a41e8b/attachment-0001.html>
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 --- Comment #4 from T?r?k Edwin --- Graphics card type: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV730 PRO [Radeon HD 4650] xorg.conf: Section "Device" Identifier "Radeon" Driver "radeon" Option "ColorTiling2D" "True" BusID "PCI:1:0:0" EndSection kernel: Linux debian 3.6.0-rc6 x86_64 Mesa build flags: ./configure --prefix=/opt/xorg --with-driver=dri --with-state-trackers="egl dri" --with-dri-drivers=i965 --with-gallium-drivers="r600 swrast" LLVM_CONFIG=/usr/bin/llvm-config-3.1 --enable-r600-llvm-compiler --enable-openvg --enable-vdpau --enable-glx-tls --enable-shared-glapi --enable-texture-float --enable-egl --enable-gallium-egl --enable-gbm --enable-gallium-gbm --with-egl-platforms=x11,drm,fbdev --enable-gles2 /opt/xorg has xserver, drm, libkms, etc. from git. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/055679ba/attachment.html>
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 T?r?k Edwin changed: What|Removed |Added Attachment #67594|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/6c442990/attachment.html>
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 T?r?k Edwin changed: What|Removed |Added Attachment #67595|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/bc459253/attachment.html>
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 T?r?k Edwin changed: What|Removed |Added Attachment #67593|text/plain |application/octet-stream mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/715a5104/attachment.html>
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 T?r?k Edwin changed: What|Removed |Added Attachment #67592|text/plain |application/octet-stream mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/a6e68884/attachment.html>
[Bug 55256] r600g R600_LLVM=1 bad rendering (light blue instead of grey)
https://bugs.freedesktop.org/show_bug.cgi?id=55256 T?r?k Edwin changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) CC||tstellar at gmail.com Component|Drivers/DRI/R600|Drivers/Gallium/r600 --- Comment #5 from T?r?k Edwin --- Sorry, chose wrong component: bug is about r600g. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120923/1a98e24b/attachment.html>
[patch] vmwgfx: corruption in vmw_event_fence_action_create()
We don't allocate enough data for this struct. As soon as we start
modifying event->event on the next lines, then we're going beyond the
end of the memory we allocated.
Signed-off-by: Dan Carpenter
---
Static checker work. Not tested.
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index f2fb8f1..7e07433 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -1018,7 +1018,7 @@ int vmw_event_fence_action_create(struct drm_file
*file_priv,
}
- event = kzalloc(sizeof(event->event), GFP_KERNEL);
+ event = kzalloc(sizeof(*event), GFP_KERNEL);
if (unlikely(event == NULL)) {
DRM_ERROR("Failed to allocate an event.\n");
ret = -ENOMEM;
