RFC: xfree: dri2: libdrm as optional
Some drivers use DRI2 protocol but implement their own kernel rendering
mananger. For these drivers, libdrm becomes useless.
The only inconvenient right now to put libdrm optional to X server is
concerning DRI2Authenticate. Such function uses drm_magic_t and drmAuthMagic
symbols from libdrm. So I thought two alternatives.
1. wrap with some macros and set at compilation time:
#ifndef WITH_DRM
typedef unsigned int drm_magic_t;
#endif
Bool
DRI2Authenticate(ScreenPtr pScreen, drm_magic_t magic)
{
#ifdef WITH_DRM
DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
if (ds == NULL || drmAuthMagic(ds-fd, magic))
return FALSE;
return TRUE;
#else
return FALSE;
#endif
}
2. hide all trickery inside xorg driver, adding a new field to DRI2InfoRec:
Bool
DRI2Authenticate(ScreenPtr pScreen, unsigned int magic)
{
DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
if (ds == NULL || (*ds-AuthMagic)(ds-fd, magic))
return FALSE;
return TRUE;
}
In the first alternative the implementation is straightforward but should be
adjusted at build time. It's ugly. Also, one would want to implement his own
way of clients authentication, or not (sigh) - note though dri2proto states
that this is not mandatory:
A kernel rendering manager can choose not to implement any
authentication and just allow access to all buffers.
Alternative 2. seems more complete but requires code changes all over the
drivers. I'm more inclined for this alternative... Moreover, for both
alternatives we need to do something with drm_magic_t type - can we just use
unsigned int instead declare such new type?
So what you guys think about this all?
Thanks,
Tiago
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] vgaarb: fix typo deference when copying from userspace
From: Brad Spengler spen...@grsecurity.net
libpciaccess is not triggering such code though.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
Andy Getzendanner tried to fix this, but he seems did a wrong approach:
http://marc.info/?l=linux-kernelm=126112173704466
Andy: please test (and put your tag review!) this one instead. Thanks.
drivers/gpu/vga/vgaarb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 1ac0c93..2f6cf69 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -961,7 +961,7 @@ static ssize_t vga_arb_write(struct file *file, const char
__user * buf,
remaining -= 7;
pr_devel(client 0x%p called 'target'\n, priv);
/* if target is default */
- if (!strncmp(buf, default, 7))
+ if (!strncmp(curr_pos, default, 7))
pdev = pci_dev_get(vga_default_device());
else {
if (!vga_pci_str_to_vars(curr_pos, remaining,
--
1.6.0.4
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH-again] vgaarb: use MIT license
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com --- Hi. All authors already decided about such change. So I'd please ask (again) that you put the s-o-b tag here. Thanks. drivers/gpu/vga/vgaarb.c | 26 +++--- include/linux/vgaarb.h | 21 + 2 files changed, 44 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c index 0f5f64d..53dd628 100644 --- a/drivers/gpu/vga/vgaarb.c +++ b/drivers/gpu/vga/vgaarb.c @@ -1,12 +1,32 @@ /* - * vgaarb.c + * vgaarb.c: Implements the VGA arbitration. For details refer to + * Documentation/vgaarbiter.txt + * * * (C) Copyright 2005 Benjamin Herrenschmidt b...@kernel.crashing.org * (C) Copyright 2007 Paulo R. Zanoni przan...@gmail.com * (C) Copyright 2007, 2009 Tiago Vignatti vigna...@freedesktop.org * - * Implements the VGA arbitration. For details refer to - * Documentation/vgaarbiter.txt + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the Software), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS + * IN THE SOFTWARE. + * */ #include linux/module.h diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h index 2dfaa29..c9a9759 100644 --- a/include/linux/vgaarb.h +++ b/include/linux/vgaarb.h @@ -5,6 +5,27 @@ * (C) Copyright 2005 Benjamin Herrenschmidt b...@kernel.crashing.org * (C) Copyright 2007 Paulo R. Zanoni przan...@gmail.com * (C) Copyright 2007, 2009 Tiago Vignatti vigna...@freedesktop.org + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the Software), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS + * IN THE SOFTWARE. + * */ #ifndef LINUX_VGA_H -- 1.6.0.4 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] vgaarb: fix trylock behaviour accordingly vga_tryget return value
From: Henry Zhao henry.z...@sun.com
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
Henry, can you Signed-off-by there?
drivers/gpu/vga/vgaarb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 2f6cf69..0f5f64d 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -935,7 +935,7 @@ static ssize_t vga_arb_write(struct file *file, const char
__user * buf,
goto done;
}
- if (vga_tryget(pdev, io_state)) {
+ if (!vga_tryget(pdev, io_state)) {
/* Update the client's locks lists... */
for (i = 0; i MAX_USER_CARDS; i++) {
if (priv-cards[i].pdev == pdev) {
--
1.6.0.4
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] vgaarb: use MIT license
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com --- Hi. I'd please ask that other copyright holders put yours s-o-b tag there. Thanks. drivers/gpu/vga/vgaarb.c | 26 +++--- include/linux/vgaarb.h | 21 + 2 files changed, 44 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c index 1ac0c93..7553cc3 100644 --- a/drivers/gpu/vga/vgaarb.c +++ b/drivers/gpu/vga/vgaarb.c @@ -1,12 +1,32 @@ /* - * vgaarb.c + * vgaarb.c: Implements the VGA arbitration. For details refer to + * Documentation/vgaarbiter.txt + * * * (C) Copyright 2005 Benjamin Herrenschmidt b...@kernel.crashing.org * (C) Copyright 2007 Paulo R. Zanoni przan...@gmail.com * (C) Copyright 2007, 2009 Tiago Vignatti vigna...@freedesktop.org * - * Implements the VGA arbitration. For details refer to - * Documentation/vgaarbiter.txt + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the Software), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS + * IN THE SOFTWARE. + * */ #include linux/module.h diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h index 2dfaa29..c9a9759 100644 --- a/include/linux/vgaarb.h +++ b/include/linux/vgaarb.h @@ -5,6 +5,27 @@ * (C) Copyright 2005 Benjamin Herrenschmidt b...@kernel.crashing.org * (C) Copyright 2007 Paulo R. Zanoni przan...@gmail.com * (C) Copyright 2007, 2009 Tiago Vignatti vigna...@freedesktop.org + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the Software), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS + * IN THE SOFTWARE. + * */ #ifndef LINUX_VGA_H -- 1.6.0.4 -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] PCI/VGA: fix header commentary
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com --- Amend this somewhere, Jesse. Thanks. include/linux/vgaarb.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h index e81c64a..290409c 100644 --- a/include/linux/vgaarb.h +++ b/include/linux/vgaarb.h @@ -1,5 +1,5 @@ /* - * vgaarb.c + * vgaarb.h * * (C) Copyright 2005 Benjamin Herrenschmidt b...@kernel.crashing.org * (C) Copyright 2007 Paulo R. Zanoni przan...@gmail.com -- 1.5.6.3 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vga: implements VGA arbitration on Linux
On Wed, Aug 12, 2009 at 06:02:14PM +0200, Jesse Barnes wrote:
On Wed, 12 Aug 2009 10:35:16 +0300
Vignatti Tiago (Nokia-D/Helsinki) tiago.vigna...@nokia.com wrote:
Okay, I can handle this documentation pretty easy.
But honestly I'm not sure we (or some future developer) will use it.
The header (include/linux/vgaarb.h) is already very nice documented.
So, tell me what do you think Jesse.
As long as it's still accurate we may as well include it.
Here it comes attached. Please review, Jesse.
Thank you,
Tiago
From f65764e41e37c9a4848bb39505e40ea55e01ddfb Mon Sep 17 00:00:00 2001
From: Tiago Vignatti tiago.vigna...@nokia.com
Date: Sun, 16 Aug 2009 17:59:01 +0300
Subject: [PATCH] vga: drops VGA arbitration documentation
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
Documentation/vgaarbiter.txt | 194 ++
1 files changed, 194 insertions(+), 0 deletions(-)
create mode 100644 Documentation/vgaarbiter.txt
diff --git a/Documentation/vgaarbiter.txt b/Documentation/vgaarbiter.txt
new file mode 100644
index 000..675119b
--- /dev/null
+++ b/Documentation/vgaarbiter.txt
@@ -0,0 +1,194 @@
+
+VGA Arbiter
+===
+
+Graphic devices are accessed through ranges in I/O or memory space. While most
+modern devices allow relocation of such ranges, some Legacy VGA devices
+implemented on PCI will typically have the same hard-decoded addresses as
+they did on ISA. For more details see PCI Bus Binding to IEEE Std 1275-1994
+Standard for Boot (Initialization Configuration) Firmware Revision 2.1
+Section 7, Legacy Devices.
+
+The Resource Access Control (RAC) module inside the X server [0] existed for
+the legacy VGA arbitration task (besides other bus management tasks) when more
+than one legacy device co-exists on the same machine. But the problem happens
+when these devices are trying to be accessed by different userspace clients
+(e.g. two server in parallel). Their address assignments conflict. Moreover,
+ideally, being an userspace application, it is not the role of the the X
+server to control bus resources. Therefore an arbitration scheme outside of
+the X server is needed to control the sharing of these resources. This
+document introduces the operation of the VGA arbiter implemented for Linux
+kernel.
+
+
+
+I. Details and Theory of Operation
+I.1 vgaarb
+I.2 libpciaccess
+I.3 xf86VGAArbiter (X server implementation)
+II. Credits
+III.References
+
+
+I. Details and Theory of Operation
+==
+
+I.1 vgaarb
+--
+
+The vgaarb is a module of the Linux Kernel. When it is initially loaded, it
+scans all PCI devices and adds the VGA ones inside the arbitration. The
+arbiter then enables/disables the decoding on different devices of the VGA
+legacy instructions. Device which do not want/need to use the arbiter may
+explicitly tell it by calling vga_set_legacy_decoding().
+
+The kernel exports a char device interface (/dev/vga_arbiter) to the clients,
+which has the following semantics:
+
+ open : open user instance of the arbiter. By default, it's attached to
+ the default VGA device of the system.
+
+ close : close user instance. Release locks made by the user
+
+ read : return a string indicating the status of the target like:
+
+ card_ID,decodes=io_state,owns=io_state,locks=io_state (ic,mc)
+
+ An IO state string is of the form {io,mem,io+mem,none}, mc and
+ ic are respectively mem and io lock counts (for debugging/
+ diagnostic only). decodes indicate what the card currently
+ decodes, owns indicates what is currently enabled on it, and
+ locks indicates what is locked by this card. If the card is
+ unplugged, we get invalid then for card_ID and an -ENODEV
+ error is returned for any command until a new card is targeted.
+
+
+ write : write a command to the arbiter. List of commands:
+
+ target card_ID : switch target to card card_ID (see below)
+ lock io_state: acquires locks on target (none is an invalid io_state)
+ trylock io_state : non-blocking acquire locks on target (returns EBUSY if
+ unsuccessful)
+ unlock io_state : release locks on target
+ unlock all : release all locks on target held by this user (not
+ implemented yet)
+ decodes io_state : set the legacy decoding attributes for the card
+
+ poll : event if something changes on any card (not just the
+ target)
+
+ card_ID is of the form PCI:domain:bus:dev.fn. It can be set to default
+ to go back to the system default card (TODO: not implemented yet). Currently,
+ only PCI is supported as a prefix, but the userland API may support other bus
+ types in the future, even if the current kernel
[PATCH 4/4] xf86-video-intel: save drm FD to be used by dri cursor (the shortcut scheme).
Signed-off-by: Tiago Vignatti vigna...@c3sl.ufpr.br
---
src/i830_dri.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/src/i830_dri.c b/src/i830_dri.c
index 07ae646..e9484bd 100644
--- a/src/i830_dri.c
+++ b/src/i830_dri.c
@@ -108,6 +108,8 @@ typedef struct drm_i915_flip {
#include dristruct.h
+#include dricursor.h
+
static Bool I830InitVisualConfigs(ScreenPtr pScreen);
static Bool I830CreateContext(ScreenPtr pScreen, VisualPtr visual,
drm_context_t hwContext, void *pVisualConfigPriv,
@@ -674,6 +676,8 @@ I830DRIScreenInit(ScreenPtr pScreen)
return FALSE;
}
+ DRICursorSaveFD(pI830-drmSubFD);
+
/* Now, nuke dri.c's dummy frontbuffer map setup if we did that. */
if (pDRIInfo-frameBufferSize != 0) {
int tmp;
--
1.5.6.3
--
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/4] X server: dricursor implementation using the X server as application.
This implementation gives two ioctls APIs (DRICursorSetDev, DRICursorHotspot)
to interface with the DRM modesetting cursors. For now this patch disables
the pointer acceleration scheme.
Signed-off-by: Tiago Vignatti vigna...@c3sl.ufpr.br
---
Makefile.am|1 +
configure.ac |4 ++-
dix/getevents.c|2 +
dricursor/Makefile.am |9 +++
dricursor/dricursor.c | 51
hw/xfree86/common/xf86Xinput.c |8 ++
hw/xfree86/ramdac/xf86Cursor.c |3 ++
include/Makefile.am|1 +
include/dricursor.h|3 ++
9 files changed, 81 insertions(+), 1 deletions(-)
create mode 100644 dricursor/Makefile.am
create mode 100644 dricursor/dricursor.c
create mode 100644 include/dricursor.h
diff --git a/Makefile.am b/Makefile.am
index aa9c8b6..c641710 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,6 +19,7 @@ endif
SUBDIRS = \
doc \
+ dricursor \
include \
dix \
fb \
diff --git a/configure.ac b/configure.ac
index 93e3a60..a83da6c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -842,6 +842,7 @@ AC_SUBST([GLX_DEFINES])
AM_CONDITIONAL(DRI, test x$DRI = xyes)
if test x$DRI = xyes; then
+DRICURSOR_LIB='$(top_builddir)/dricursor/libdricursor.la'
AC_DEFINE(XF86DRI, 1, [Build DRI extension])
PKG_CHECK_MODULES([DRIPROTO], [xf86driproto])
PKG_CHECK_MODULES([LIBDRM], [libdrm = 2.3.0])
@@ -1228,7 +1229,7 @@ if test x$XORG = xyes; then
XORG_OSINCS='-I$(top_srcdir)/hw/xfree86/os-support
-I$(top_srcdir)/hw/xfree86/os-support/bus -I$(top_srcdir)/os'
XORG_INCS=$XORG_DDXINCS $XORG_OSINCS
XORG_CFLAGS=$XORGSERVER_CFLAGS -DHAVE_XORG_CONFIG_H
- XORG_LIBS=$COMPOSITE_LIB $FIXES_LIB $XEXTXORG_LIB $GLX_LIBS
$RENDER_LIB $RANDR_LIB $DAMAGE_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB
$XKB_LIB $SELINUX_LIB
+ XORG_LIBS=$COMPOSITE_LIB $FIXES_LIB $XEXTXORG_LIB $GLX_LIBS
$RENDER_LIB $RANDR_LIB $DAMAGE_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB
$XKB_LIB $SELINUX_LIB $DRICURSOR_LIB
PKG_CHECK_MODULES([PCIACCESS], [pciaccess = 0.8.0])
SAVE_LIBS=$LIBS
@@ -1803,6 +1804,7 @@ damageext/Makefile
dbe/Makefile
dix/Makefile
doc/Makefile
+dricursor/Makefile
fb/Makefile
record/Makefile
config/Makefile
diff --git a/dix/getevents.c b/dix/getevents.c
index 4770a69..8d24075 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -880,12 +880,14 @@ GetPointerEvents(EventList *events, DeviceIntPtr pDev,
int type, int buttons,
}
}
else {
+#if 0
if (flags POINTER_ACCELERATE
pDev-valuator-accelScheme.AccelSchemeProc){
pDev-valuator-accelScheme.AccelSchemeProc(
pDev, first_valuator, num_valuators, valuators, ms);
}
+#endif
if(v0) x += *v0;
if(v1) y += *v1;
diff --git a/dricursor/Makefile.am b/dricursor/Makefile.am
new file mode 100644
index 000..017a861
--- /dev/null
+++ b/dricursor/Makefile.am
@@ -0,0 +1,9 @@
+noinst_LTLIBRARIES = libdricursor.la
+
+AM_CFLAGS = @DIX_CFLAGS@ @LIBDRM_CFLAGS@
+
+INCLUDES = $(XORG_INCS) \
+ -I$(top_srcdir)/include
+
+libdricursor_la_SOURCES = dricursor.c
+libdricursor_la_LIBADD = @LIBDRM_LIBS@
diff --git a/dricursor/dricursor.c b/dricursor/dricursor.c
new file mode 100644
index 000..933baac
--- /dev/null
+++ b/dricursor/dricursor.c
@@ -0,0 +1,51 @@
+#ifdef HAVE_DIX_CONFIG_H
+#include dix-config.h
+#endif
+
+#include stdio.h
+#include xf86drm.h
+#include dricursor.h
+
+
+int drmFD = -1;
+
+/**
+ * Save the DRM fd. Called by the DRM user, i.e. the video driver.
+ *
+ * @param The drm file-descriptor
+ */
+void
+DRICursorSaveFD(int fd) {
+fprintf(stderr, %s: %d\n, __FUNCTION__, fd);
+drmFD = fd;
+}
+
+/**
+ * drmCursorSetDev ioctl interface.
+ *
+ * Notify DRM about which devices are responsible for cursor updates.
+ *
+ * @param The device path (e.g. /dev/input/event0)
+ * @return On success zero is returned.
+ */
+int
+DRICursorSetDev(char *path)
+{
+fprintf(stderr, %s: %d: %s\n, __FUNCTION__, drmFD, path);
+return drmCursorSetDev(drmFD, path);
+}
+
+/**
+ * drmCursorHotspot ioctl interface.
+ *
+ * When the application updates the sprite, DRM must be notified by the
+ * changes.
+ *
+ * @param The hotspot of the cursor.
+ * @return On success zero is returned.
+ */
+int
+DRICursorHotspot(int hotx, int hoty)
+{
+return drmCursorHotspot(drmFD, hotx, hoty);
+}
diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
index 8eaa118..c4f3f30 100644
--- a/hw/xfree86/common/xf86Xinput.c
+++ b/hw/xfree86/common/xf86Xinput.c
@@ -89,6 +89,7 @@
#endif
#include os.h
+#include dricursor.h
EventListPtr xf86Events = NULL;
@@ -471,6 +472,7 @@ NewInputDeviceRequest (InputOption *options, DeviceIntPtr
*pdev)
DeviceIntPtr dev = NULL;
int rval = Success;
int is_auto = 0
[PATCH 3/4] evdev: short-circuit evdev with drm to update cursors in-kernel.
Signed-off-by: Tiago Vignatti vigna...@c3sl.ufpr.br
---
drivers/input/evdev.c | 11 +++
include/linux/drm_cursor.h |3 +++
2 files changed, 14 insertions(+), 0 deletions(-)
create mode 100644 include/linux/drm_cursor.h
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 3524bef..2b7742e 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -21,6 +21,11 @@
#include linux/device.h
#include linux/compat.h
+#define DRM_CURSOR
+#ifdef DRM_CURSOR
+#include linux/drm_cursor.h
+#endif
+
struct evdev {
int exist;
int open;
@@ -77,6 +82,12 @@ static void evdev_event(struct input_handle *handle,
event.code = code;
event.value = value;
+#ifdef DRM_CURSOR
+/* TODO: we can do this shortcut better using a callback scheme thus
+ * drm won't be a dependency for the evdev module */
+drm_collect_input_event(evdev-name, event);
+#endif
+
rcu_read_lock();
client = rcu_dereference(evdev-grab);
diff --git a/include/linux/drm_cursor.h b/include/linux/drm_cursor.h
new file mode 100644
index 000..aa983d9
--- /dev/null
+++ b/include/linux/drm_cursor.h
@@ -0,0 +1,3 @@
+#include linux/input.h
+
+void drm_collect_input_event(const char *name, struct input_event *ev);
--
1.5.6.3
--
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/4] DRM: in-kernel cursor update on the top of mode setting.
This commit adds support for the DRM in-kernel cursor mode setting APIs.
When drm_mode_setcrtc is called we also initialize the cursor routines.
Through drmCursorSetDev, the userspace app (e.g. Xorg, wayland) tells which
devices are responsible for cursors' updates and the kernel input layer
will spit the events to DRM (drm_collect_input_event). DRM will take
care about the event informations and also screen limits, and then will
draw the cursor on screen.
Signed-off-by: Tiago Vignatti vigna...@c3sl.ufpr.br
---
libdrm/xf86drm.c | 20
libdrm/xf86drm.h |4 +
libdrm/xf86drmMode.c |4 +-
linux-core/Makefile.kernel |4 +-
linux-core/drm_crtc.c |3 +
linux-core/drm_crtc.h |4 +
linux-core/drm_cursor.c| 214
linux-core/drm_cursorP.h |1 +
linux-core/drm_drv.c |2 +
shared-core/drm.h | 11 +++
10 files changed, 264 insertions(+), 3 deletions(-)
create mode 100644 linux-core/drm_cursor.c
create mode 100644 linux-core/drm_cursorP.h
diff --git a/libdrm/xf86drm.c b/libdrm/xf86drm.c
index 7b67813..b8f12b6 100644
--- a/libdrm/xf86drm.c
+++ b/libdrm/xf86drm.c
@@ -2994,3 +2994,23 @@ int drmDropMaster(int fd)
ret = ioctl(fd, DRM_IOCTL_DROP_MASTER, 0);
return ret;
}
+
+int drmCursorSetDev(int fd, char *name)
+{
+struct drm_mode_cursor_setdev arg;
+
+strncpy(arg.name, name, strlen(name));
+arg.name[strlen(name)] = '\0';
+
+return ioctl(fd, DRM_IOCTL_MODE_CURSORSETDEV, arg);
+}
+
+int drmCursorHotspot(int fd, int hotx, int hoty)
+{
+struct drm_mode_cursor_hotspot arg;
+
+arg.hotx = hotx;
+arg.hoty = hoty;
+
+return ioctl(fd, DRM_IOCTL_MODE_CURSORHOTSPOT, arg);
+}
diff --git a/libdrm/xf86drm.h b/libdrm/xf86drm.h
index 35780ac..04b7faa 100644
--- a/libdrm/xf86drm.h
+++ b/libdrm/xf86drm.h
@@ -663,6 +663,10 @@ extern void drmCloseOnce(int fd);
extern int drmSetMaster(int fd);
extern int drmDropMaster(int fd);
+/* In-kernel cursor update routines */
+extern int drmCursorSetDev(int fd, char *name);
+extern int drmCursorHotspot(int fd, int hotx, int hoty);
+
#include xf86mm.h
#endif
diff --git a/libdrm/xf86drmMode.c b/libdrm/xf86drmMode.c
index c3921ee..e3a1c76 100644
--- a/libdrm/xf86drmMode.c
+++ b/libdrm/xf86drmMode.c
@@ -325,7 +325,9 @@ int drmModeMoveCursor(int fd, uint32_t crtcId, int x, int y)
arg.x = x;
arg.y = y;
- return ioctl(fd, DRM_IOCTL_MODE_CURSOR, arg);
+/* Just to see that we're doing the things correctly :)
+ * return ioctl(fd, DRM_IOCTL_MODE_CURSOR, arg); */
+return 1;
}
/*
diff --git a/linux-core/Makefile.kernel b/linux-core/Makefile.kernel
index 246c0b3..53f5795 100644
--- a/linux-core/Makefile.kernel
+++ b/linux-core/Makefile.kernel
@@ -7,8 +7,8 @@
# $XFree86:
xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Makefile.kernel,v
1.18 2003/08/16 17:59:17 dawes Exp $
#
-drm-objs:= drm_auth.o drm_bufs.o drm_context.o drm_dma.o drm_drawable.o \
- drm_drv.o drm_fops.o drm_ioctl.o drm_irq.o \
+drm-objs:= drm_auth.o drm_bufs.o drm_context.o drm_cursor.o drm_dma.o \
+ drm_drawable.o drm_drv.o drm_fops.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_proc.o drm_stub.o drm_vm.o \
drm_sysfs.o drm_pci.o drm_agpsupport.o drm_scatter.o \
drm_memory_debug.o ati_pcigart.o drm_sman.o \
diff --git a/linux-core/drm_crtc.c b/linux-core/drm_crtc.c
index 7ee3321..e015342 100644
--- a/linux-core/drm_crtc.c
+++ b/linux-core/drm_crtc.c
@@ -33,6 +33,7 @@
#include drm.h
#include drmP.h
#include drm_crtc.h
+#include drm_cursorP.h
struct drm_prop_enum_list {
int type;
@@ -1412,6 +1413,8 @@ int drm_mode_setcrtc(struct drm_device *dev,
set.fb =fb;
ret = crtc-funcs-set_config(set);
+drm_cursor_init(crtc);
+
out:
kfree(connector_set);
mutex_unlock(dev-mode_config.mutex);
diff --git a/linux-core/drm_crtc.h b/linux-core/drm_crtc.h
index bfccdeb..15e9aca 100644
--- a/linux-core/drm_crtc.h
+++ b/linux-core/drm_crtc.h
@@ -676,6 +676,10 @@ extern int drm_mode_setcrtc(struct drm_device *dev,
void *data, struct drm_file *file_priv);
extern int drm_mode_cursor_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
+extern int drm_mode_cursor_setdev_ioctl(struct drm_device *dev,
+void *data, struct drm_file *file_priv);
+extern int drm_mode_cursor_hotspot_ioctl(struct drm_device *dev,
+void *data, struct drm_file *file_priv);
extern int drm_mode_addfb(struct drm_device *dev,
void *data, struct drm_file *file_priv);
extern int drm_mode_rmfb(struct drm_device *dev,
diff --git a/linux-core/drm_cursor.c b/linux-core/drm_cursor.c
new file mode 100644
index 000..832e3b1
--- /dev/null
+++ b/linux-core/drm_cursor.c
@@ -0,0 +1,214
[PATCH 0/4] Cursor's update inside kernel only
Hi guys, Under KMS, we can build a feature to update the cursor directly to screen without the continuous intervention of the userspace application (X server, wayland, etc). It's a fastpath for DRM based cursors obtained by short-circuit the kernel input layer and DRM module. This would solve all cursor's latency issues that we have in our current model [0]. This series of patches implement such feature using Xorg as the application. Through an ioctl, Xorg tells which devices are responsible for cursors' updates and the kernel evdev driver will spit the events to DRM. DRM will take care about the event informations and also screen limits, and then will draw the cursor on screen. Very intuitive. Right now a thing that is annoying me is how others cursors, sw rendered, could be implemented. I want to avoid two differents sets of the same code in different contexts. IMHO conceptually all these cursor update things must be in-kernel. Painting a cursor image seems to be quite hard as we have to save/restore areas under the cursor. I remember that anholt had an idea concerning this, but I do not remember details. Well, the patches are far from ready to go upstream, but it deploys a system working on this way. So, for now, this mail has two goals: - to people comment on and see in what kind of world we can move. - get a feedback how we can proceed in the case of sw cursors. Please, comment on. Thank you, [0] http://vignatti.wordpress.com/2008/07/29/improving-input-latency/ -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Improving input latency
kernel as well (the current implementation of accel deals with floats, so we would have to adapt it to live in kernel). It is a _very_ _large_ amount of codification. It would require changes to the X server, DDX driver and its corresponding kernel DRM drivers, drm library and kernel input drivers. A mini-input driver *inside* drm is also needed. We would add complexities of the connection between input device and output device to the kernel (in my proof-of-concept implementation evdev is dependent of drm. Yeah, really weird world). Moreover, we would have to avoid somehow two differents sets of the exact same code in different contexts in the case of sw cursors (think MPX). It's a completely redesign. Things would have to go incrementally. But why this strategy? Well, this would solve all the current issues with input latency. For instance with the current design of the kernel modesetting - which seems the future - the cursor is jumping a lot, much more than with current implementation. Try to call a xrandr instance and move the mouse with kernel modesetting. xrandr will do DDC communication which will blocked X in the kernel. So with the handling and update of the cursor inside the kernel all would work fine (and my proof-of-concept already showed this). Moreover, I believe the current implementation remained until now due historical reasons. Ultrix systems placed the entire input subsystem in the kernel. What is the problem to do this in Linux (and others) as well (besides massive codification)? and non-dri drivers? Should we forget them? EOF -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
Stephane Marchesin escreveu: On Fri, Jul 11, 2008 at 1:12 AM, Tiago Vignatti [EMAIL PROTECTED] wrote: Yeah, but the current design in the kms (i.e. DRM touching the registers) is not good as well. The pointer is jumping a lot -- much more than the old design -- because with a single device movement it emits a hundred of events and a lot of context switch is done. Not cool. Care to elaborate ? What you describe here sounds like an implementation-specific issue, more than an issue with KMS. Okay, I lied here ;) The reason of the cursor jumping is not the number of context switches. Dave helped me to identify the real reason. Try to call a xrandr instance and move the mouse with kernel modesetting. xrandr will do DDC communication which will blocked X in the kernel. With my implementation of the X server using a separate thread to take care the input events this is _reduced_ because signals is not used to wake up the devices. Moreover, with the handling and update of the cursor inside the kernel all would work perfectly smooth (in fact I tried it with my proof-of-concept and it was confirmed). Thanks you, -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
cursor handling and updates inside DRM
Hi, The current DRM kernel modesetting tree is already taking care to update the cursor registers and paint it to the screen. Very cool [0]. What I've done today is a shortcut between the kernel input layer and DRM to update the cursor directly on screen without the X server be notified always. Of course, a lot of issues raised up together. So let's try to delegates the tasks again. userspace app (X server): - starts all this mechanism telling which is the device responsible for the cursor (input ddx drv) - responsible for loading new cursor images and push to the DRM (video ddx drv) kernel input layer (evdev driver): - notify and send its relative coordinates events to DRM DRM: - transform relative motion into absolute - takes care the cursor limits - responsible for the acceleration computation - responsible for the input transformation as well? - touch the gfx registers. Seems that a reasonable amount of code in ddx input drv (mainly ReadInput) and dix (mainly GetPointerEvents) would be swallowed by the DRM. The event generation stage of the server would deal with the event itself + xkb + Xi things (which eventually could be done in a dedicated thread) and will let to DRM the responsibility of paint the cursor on screen. The communication between kernel input drv can be directly, calling a DRM function; the DRM and userspace can communicate basically using ioctls. Complains? This would only works with DRM supporting OSes. What about the others? Thank you, [0] Not so much. Seems this method to update the cursor is sending _a lot of_ ioctls and sometimes doing cursor jumps. But I have to double check to see if the problem is for sure with context switches. -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
Daniel Stone escreveu: On Thu, Jul 10, 2008 at 04:05:57AM -0300, Tiago Vignatti wrote: - transform relative motion into absolute - takes care the cursor limits - responsible for the acceleration computation - responsible for the input transformation as well? - touch the gfx registers. Hang on, are we actually putting all this in the kernel? Yes, Daniel. This was my first thought. Now I'm trying to discuss with you how we can distribute this things between X, drm and kernel. -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
Simon Thum escreveu: But all this in the kernel is an impedance mismatch to me. What could it buy us we don't have today? Improve heavy-load behavior -- no jumping pointer. (BTW, your mouse acceleration proposal [0] doesn't do it at all.) Cheers, [0] https://bugs.freedesktop.org/attachment.cgi?id=17545 This doc says that it improves the heavy-load behavior, but I'm failing to see it. Can you be more specific? -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: cursor handling and updates inside DRM
Hi Jakob, Jakob Bornecrantz escreveu: The only thing that should be in the kernel is the: - touch the gfx registers. and in some regards - takes care of the cursor limits. Anything else is the client responsibility. The coordinates that we feed the kernel will be relative to the crtc and in pixels of scanout buffer. We do not have a 2D/3D acceleration API in the kernel. Nor should we have a mouse position calculation API in the kernel either. Cursor is in the kernel because in the new world of kernel modesetting you don't map registers to userspace you talk to them via the kernel. I am a bit divided if any of the above have a place in the DRM userspace library. Yeah, but the current design in the kms (i.e. DRM touching the registers) is not good as well. The pointer is jumping a lot -- much more than the old design -- because with a single device movement it emits a hundred of events and a lot of context switch is done. Not cool. -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'modesetting-101' - 2 commits
Hi Maarten,
Maarten Maathuis escreveu:
linux-core/drm_crtc.c | 96 +++-
linux-core/drm_crtc.h | 50 +
linux-core/drm_sysfs.c| 98
+
linux-core/intel_tv.c |2
linux-core/nv50_connector.h |1
linux-core/nv50_kms_wrapper.c | 100
--
linux-core/nv50_kms_wrapper.h |1
shared-core/drm.h | 56 +--
8 files changed, 345 insertions(+), 59 deletions(-)
New commits:
commit c9915d695dad8e4f75b4f551f9f78ff3d64dc666
Author: Maarten Maathuis [EMAIL PROTECTED]
Date: Fri Jul 4 17:28:04 2008 +0200
modesetting-101: Move some defines used for enumeration into the public
header.
- Otherwise userspace has no idea of the meaning.
diff --git a/linux-core/drm_crtc.h b/linux-core/drm_crtc.h
index caceb65..d4bb879 100644
--- a/linux-core/drm_crtc.h
+++ b/linux-core/drm_crtc.h
@@ -90,6 +90,8 @@ enum drm_mode_status {
.vsync_start = (vss), .vsync_end = (vse), .vtotal = (vt), \
.vscan = (vs), .flags = (f), .vrefresh = 0
+#define CRTC_INTERLACE_HALVE_V 0x1 /* halve V values for interlacing */
+
struct drm_display_mode {
/* Header */
struct list_head head;
@@ -147,51 +149,6 @@ struct drm_display_mode {
float hsync;
};
-/* Video mode flags */
-#define V_PHSYNC (10)
-#define V_NHSYNC (11)
-#define V_PVSYNC (12)
-#define V_NVSYNC (13)
-#define V_INTERLACE (14)
-#define V_DBLSCAN(15)
-#define V_CSYNC (16)
-#define V_PCSYNC (17)
-#define V_NCSYNC (18)
-#define V_HSKEW (19) /* hskew provided */
-#define V_BCAST (110)
-#define V_PIXMUX (111)
-#define V_DBLCLK (112)
-#define V_CLKDIV2(113)
...
--- a/shared-core/drm.h
+++ b/shared-core/drm.h
@@ -1010,6 +1010,28 @@ struct drm_mm_info_arg {
#define DRM_MODE_TYPE_USERDEF(15)
#define DRM_MODE_TYPE_DRIVER (16)
+/* Video mode flags */
+#define V_PHSYNC (10)
+#define V_NHSYNC (11)
+#define V_PVSYNC (12)
+#define V_NVSYNC (13)
+#define V_INTERLACE (14)
+#define V_DBLSCAN(15)
+#define V_CSYNC (16)
+#define V_PCSYNC (17)
+#define V_NCSYNC (18)
+#define V_HSKEW (19) /* hskew provided */
+#define V_BCAST (110)
+#define V_PIXMUX (111)
+#define V_DBLCLK (112)
+#define V_CLKDIV2(113)
This commit is causing conflict with the X server letting it doesn't
compile anymore. Those video mode flags are already defined in
hw/xfree86/common/xf86str.h.
Cheers,
Tiago Vignatti
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GSOC '08 hardware accelerated video decoding
to support off-loading more stages and more video formats. VAAPI is not currently supported widely by user applications, but this could offer incentive to application developers. * Implementation of various filters to improve visual quality. De-interlacing, de-blocking, de-ringing, bi-cubic interpolation, and others would be investigated for possible implementation. Project Details: The XvMC implementation: This implementation will be written in terms of Gallium3D using the SoftPipe driver, a software driver, and a fork of libXvMC from the openChrome project as a starting point. This will allow the implementation to be tested against a working reference driver, after which point development will switch to actual hardware. The level of support that the current Gallium3D Nvidia implementation offers will be evaluated and any deficiencies will be addressed. It is expected that the XvMC implementation will require vertex and pixel shader support, texturing support, and render target support, amongst other things. The implementation itself will be composed of C source code that will be compiled as part of the nouveau driver (TODO: Get clarification on this--part of nouveau, Gallium3D?) and vertex and pixel shader code that will execute on the GPU. User applications: The user applications will serve as benchmarks for the implementation. Several user applications have support for XvMC and can be used to verify functional and performance characteristics. VLC and MPlayer are good candidates for example. Alternative hardware drivers: Alternative hardware drivers, in addition to the SoftPipe driver, can also be used as a reference, especially for performance comparisons. The Nvidia binary driver supports XvMC and implements IDTC and MC for MPEG2 video and can serve as a reference. Related Work: [1] Accelerate Video Decoding With Generic GPU - Guobin Shen, Guang-Ping Gao, Shipeng Li, Heung-Yeung Shum, and Ya-Qin Zhang - http://research.microsoft.com/~jackysh/publications/Accelerate%20video%20decoding%20with%20generic%20GPU.pdf This paper describes the implementation of the color space conversion (CSC) and motion compensation (MC) stages of the video decoding pipeline via the GPU programmable pipeline. The authors state that they were able to achieve real-time 720p HD play back on a Pentium III 667 MHz CPU and GeForce3 GPU. [2] Techniques for Efficient DCT/IDCT Implementation on Generic GPU - Bo Fang, Guobin Shen, Shipeng Li, and Huifang Chen - http://research.microsoft.com/~jackysh/publications/iscas2005%20--%20Techniques%20for%20Efficient%20DCT_IDCT%20Implementation%20on%20Generic%20GPU.pdf An extension of the previous paper, where the authors also implement the inverse discrete cosine transform (IDCT) stage of the video decoding pipeline. They note that while their implementation is competitive, an optimized CPU SIMD implementation is still somewhat faster for this stage. [3] XvMC via dedicated hardware on Nvidia GPUs - http://nouveau.freedesktop.org/wiki/jb17bsome User jb17bsome is working towards XvMC support in the nouveau driver via dedicated video decoding hardware on Nvidia GPUs, as opposed to using the programmable GPU pipeline. Personal Details: My name is Younes Manton; I am currently a computer science student at York University in Toronto, Canada. I am interested in low-level computer architecture, compiler theory and design, 2D and 3D graphics technology, and video and audio decoding. For the last year I have been employed as an intern in IBM's compiler group, working on performance analysis for the XL C, C++, and Fortran compilers for PowerPC and CELL. As my internship winds down I hope to participate in the Summer of Code program on a project that is in line with my interests and is useful to the OSS community. Skills: * Well-versed in C, C++, and a variety of assembly languages (x86, PPC, CELL-SPU, SuperH, MIPS) * Well-versed in the Direct3D and OpenGL APIs, and various shading languages * Experienced with low-level programming, having worked on various embedded systems * TODO: Add more relevant skills, add evidence Plans: As my internship at IBM winds down I hope to have sufficient free time to undertake the above. I do not plan on taking any courses during the summer, but will be employed on a part-time basis as a necessity. I hope to devote an average of 20 hours per week to this work and will strive to meet expectations and deliver a successful project. I have identified a minimum set of deliverables that I feel will still make this project worthwhile for myself, the Google Summer of Code program, and the mentoring organization, but have also provided a larger set of goals that will be nice to have and that I am optimistic in achieving, at least partially. Very cool your proposal but watch out the 7500-character limit. Cheers, -- Tiago Vignatti C3SL - Centro de
Re: DRI Summer of Code ?
Keith Packard escreveu: On Sun, 2008-03-02 at 20:41 +0100, Jerome Glisse wrote: Well i haven't replied on irc because i fear i won't have much time this summer (hoping to finaly take some holidays :)) but i think i can still manage to help someone. My bigest concern is about what kind of project someone with zero knowledge on the dri stuff can tackle in 2 months. The X.org board treats GSoC as an opportunity to teach new developers rather than a chance to get a pile of free code. With this perspective, if, in two months, the student actually has learned how to contribute to DRI, that's a huge step forward. Creating a project which guides this process with a maximal chance of success is the only tricky part. Beautiful! I quoted this in Xorg wiki, if you don't mind :) -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 committed
Dan Nicholson escreveu:
On Thu, Feb 21, 2008 at 9:33 AM, Tiago Vignatti [EMAIL PROTECTED] wrote:
Also, with DRI2 we have to explicit pass --disable-dri2 flag to autoconf
because Xorg uses dri_sarea.h which is external to X server (from mesa).
Is this good enough?
Update mesa. ajax added dri_sarea.h to the installation a couple days ago.
Exactly.
With DRI we can build the Xorg without pass the source of mesa and the
DRI extension is built. With DRI2 this is not true and mesa becomes a
dependency to Xorg.
(Anyway, it doesn't make sense to build Xorg with DRI{,2} extension but
without mesa. So forget it all. It's just a matter to set --disable-dri2
flag)
Thank you,
--
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: redesigning the DRM internal logic..
Hi guys, Keith Packard escreveu: On Wed, 2008-02-13 at 19:22 -0500, Alex Deucher wrote: How about a compat node for old clients and a new render node that handles both new clients and GPGPU? Then the backwards compat stuff could just be a shim layer and everything else could use the same code instead of dealing with separate render and gpgpu nodes. Recall that one of the goals is to support multiple user sessions running at the same time, so we really do want to have per-session 'devices' which relate the collection of applications running within that session and reflect the access permissions of the various objects and methods within that session. I'm not sure what the scope of the work you're proposing here, but in a not so long future I'll need to glue this with the VGA arbitration code [0]. We need to design something about the case where the cards generate an interrupt when the arbiter has disable MEM decoding, for instance. Someone already mentioned about implement a driver callback for disabling IRQ emission on a given card when it's being disabled by the arbiter. But I don't know for sure yet. Do you have an idea where I'll need to hook this all? Thanks, [0] http://www.x.org/wiki/VgaArbiter Anyway, this things aren't *so* updated. I have more code here synced with the master branch of X server but currently I'm fighting with some pciaccess drivers which refuse to initialize a secondary card. Sigh. -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Hi, [EMAIL PROTECTED] escreveu: On Sun, Aug 12, 2007 at 09:36:32PM -0700, Jesse Barnes wrote: On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote: I fail to understand why you want to put the manager in a daemon, instead of just letting the kernel do the management, like it does for all other hardware. Why is graphics hardware supposed to be different in this regard? Graphics hardware is somewhat different in this regard due to the large userland component to the driver. The userland component, translating abstract requests into low-level hardware-specific commands, is is large; and this is fine. My point was that *management* -- which is *not* large -- belongs into the kernel. It just doesn't make sense to have console setup and console switching -- which, on a monolithic system, is part of the kernel -- depend on a userspace daemon. This would be almost as bad as the current situation, where a userspace daemon called X server is doing all the management... Well, I'm not sure it's quite as bad as you make out. The kernel must still come up with *some* initial mode, though this may typically be whatever the bootloader gave us at handoff time. Once the kernel has started init, however, a userspace program (call it 'gfxmgr') can do full output probing (i.e. monitor mode detection, output-crtc mapping, and initial mode picking) taking better advantage of the hardware. The 'gfxmgr' program should be *much* smaller than the X server, since it will be doing far less--just output probing and access control, not full mode setting (the kernel will do this), protocol management, and client scheduling. Well, obviously it's an improvement to move this functionality out of the big server; yet the fundamental problems remain the same. I am *not* opposed to a scheme where userspace has to provide information how to set up a desired mode. (Although I'm not conviced it's really necessary -- both Keith Packard and Dave Airlie argued that mode setting is simple enough to be done in the kernel completely...) However, I do not see why some central daemon should be involved when an X server or framebuffer application or console driver or whatever wants to set up a mode on its VT; or if the system is suspended/resumed. As I pointed out in my FOSDEM talk, the kernel does *not* strictly need to know how to determine what modes are available, or how to set up a mode with desired properties -- this can be handled by the client. However, the kernel *does* need to know enough about the hardware, to be able to safely switch between arbitrary client-supplied modes. (Or back to a default mode, if a client dies.) Any scheme that tries to delegate this knowledge to some external daemon, is inherently complicated and fragile, and will end up with the very same problems we have today. I hope you guys are not forgetting who wants to start two (or more) instances of the Xorg server (for multiseat purposes or what ever). In this case, the daemon - in kernel or not - would be useful to handle the routing of the VGA code to the right legacy cards. An external daemon is also needed to control the resources provided by the vga card in the case of multiseat (which would be overlapped in a multi-head environment if the Resource Access Control (RAC) never existed on Xorg). -- Tiago Vignatti C3SL - Centro de Computação Científica e Software Livre www.c3sl.ufpr.br - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
