答复: [PATCH]siliconmotion new driver initial patch
Hi Alan, Thank you for your reply. We will change the configure.ac/Makefile.am. But one more thing I need your advice. This is a initial patch. There are many code has been changed. In order to make the patch smaller shall I separate the patch into small parts? What kind of small parts shall I made? Aaron -邮件原件- 发件人: Alan Coopersmith [mailto:alan.coopersm...@oracle.com] 发送时间: 2012年8月13日 22:35 收件人: Aaron.Chen 陈俊杰 抄送: xorg-devel@lists.x.org 主题: Re: [PATCH]siliconmotion new driver initial patch On 08/12/12 11:07 PM, Aaron.Chen 陈俊杰 wrote: I didn't found this mail show up on the xorg-devel mail list and there is no response. Maybe it didn't sent successfully, so I sent it again. 2.2 MB mails require moderator approval to be sent to the mailing list. Please don't send multiple copies of multi-megabyte mails. Though really, you can also assume sending a single 2.2MB patch is a waste of time that no one will ever review, especially since the first few files shown continue to repeat mistakes we already told you we would not accept, such as undoing past cleanups of configure.ac/Makefile.am to revert them to older, less functional states. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 3/3] Kludge -- Call RandR screen before cleaning up xf86 crtcs
On Wed, Aug 8, 2012 at 10:49 AM, Keith Packard kei...@keithp.com wrote: The core RandR screen cleanup now involves cleaning up any GPU screen associations, and those call down into DDX to clean up the driver. If the pointers from the xf86 structures back to the core randr structures are set to NULL at that point, bad things happen. This patch knows that the core RandR close screen is underneath the xf86 randr close screen function, and so makes sure it gets called first. Yeah its pretty kludgey but probably the best solution for now. Reviewed-by: Dave Airlie airl...@redhat.com Signed-off-by: Keith Packard kei...@keithp.com --- hw/xfree86/modes/xf86Crtc.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c index 154f684..1947c5be 100644 --- a/hw/xfree86/modes/xf86Crtc.c +++ b/hw/xfree86/modes/xf86Crtc.c @@ -726,6 +726,12 @@ xf86CrtcCloseScreen(ScreenPtr screen) xf86RotateCloseScreen(screen); +xf86RandR12CloseScreen(screen); + +free(config-name); + +screen-CloseScreen(screen); + for (o = 0; o config-num_output; o++) { xf86OutputPtr output = config-output[o]; @@ -749,10 +755,7 @@ xf86CrtcCloseScreen(ScreenPtr screen) else if (screen-current_master) DetachUnboundGPU(screen); } -xf86RandR12CloseScreen(screen); - -free(config-name); -return screen-CloseScreen(screen); +return TRUE; } /* -- 1.7.10.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Extension of Xorg server 32/64 Bits problem - SOLVED!
Hi, Just for Information: I had a strange problem with a small loadable extention for Xorg server but only on 64-Bit system. On 32-Bit Linux System the extention works fine, on 64-Bit system I got an error X Error of failed request: BadLength (poly request too large or internal Xlib length error). I have asked here in forum but nothing helps :( Now I know what the problem was and hope, this solution will help somebody who try to write a loadable extension too. Simply the /usr/include/xorg/xorg-server.h was missed! That is a generated header file and must be included at the first place in the extension AND NOT in the client application / lib! After including it the _XSERVER64 flag is set to 1 and everything allright!… HTH Leo ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Extension of Xorg server 32/64 Bits problem
Hi, Just for Information: I had a strange problem with a small loadable extention for Xorg server but only on 64-Bit system. On 32-Bit Linux System the extention works fine, on 64-Bit system I got an error X Error of failed request: BadLength (poly request too large or internal Xlib length error). I have asked here in forum but nothing helps Now I know what the problem was and hope, this solution will help somebody who try to write a loadable extension too. Simply the /usr/include/xorg/xorg-server.h was missed! That is a generated header file and must be included at the first place in the extension AND NOT in the client application / lib! After including it the _XSERVER64 flag is set to 1 and everything allright!… HTH Leo ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xauth: improve to handle FamilyWild necessary for GDM/XDMCP/SSH. #43425
Hello xorg-devel, [ please CC me in your replies ] This is an updated version of Tilmann Bubeck's patch for #43425 fixing remarks by Walter Harms. This patch is needed in case you use the following setup Client-VNC-XDMCP (localhost)-GDM In the above scenario you won't be able to forward your Display using X11: ssh -X $OTHERHOST xterm Warning: No xauth data; using fake authentication data for X11 forwarding. Invalid MIT-MAGIC-COOKIE-1 keyxset: unable to open display localhost:10.0 Invalid MIT-MAGIC-COOKIE-1 keyxterm Xt error: Can't open display: localhost:10.0 Original log message: xauth is currently unable to handle FamilyWild. This gives problems with GDM receiving XDMCP request which used FamilyWild. More details in the referenced freedesktop bugzilla entry. The patch improves xauth to handle that Family: * allow dump_entry to deal with that Family and output such entries correctly. * allow list $DISPLAY to match against an entry in XAUTHORITY of type FamilyWild. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=43425 [ -- cut here -- ] diff --git a/process.c b/process.c index 283b4a1..49d1b13 100644 --- a/process.c +++ b/process.c @@ -462,7 +462,10 @@ read_auth_entries(FILE *fp, Bool numeric, AuthList **headp, AuthList **tailp) return n; } -static Bool +/** + * Parse the given displayname and build a corresponding AuthList. + */ +static Bool get_displayname_auth(const char *displayname, AuthList **authl) { int family; @@ -991,6 +994,9 @@ dump_entry(const char *inputfilename, int lineno, Xauth *auth, char *data) fwrite (auth-address, sizeof (char), auth-address_length, fp); fprintf (fp, /unix); break; + case FamilyWild: + fwrite (auth-address, sizeof (char), auth-address_length, fp); + break; case FamilyInternet: #if defined(IPv6) defined(AF_INET6) case FamilyInternet6: @@ -1073,6 +1079,39 @@ match_auth_dpy(register Xauth *a, register Xauth *b) memcmp(a-number, b-number, a-number_length) == 0) ? 1 : 0); } +static int +match_authwild_dpy(register Xauth *a, const char *displayname) +{ +int family; +char *host = NULL, *rest = NULL; +int dpynum, scrnum; +char dpynumbuf[40];/* want to hold largest display num */ + +if ( a-family != FamilyWild ) { + return False; +} + +if (!parse_displayname (displayname, + family, host, dpynum, scrnum, rest)) { + if (host) free(host); + if (rest) free(rest); + + return False; +} + +dpynumbuf[0] = '\0'; +sprintf (dpynumbuf, %d, dpynum); + +if (a-address_length != strlen(host) || a-number_length != strlen(dpynumbuf)) + return False; + +if (memcmp(a-address, host, a-address_length) == 0 + memcmp(a-number, dpynumbuf, a-number_length) == 0) + return True; +else + return False; +} + /* return non-zero iff display and authorization type are the same */ static int @@ -1236,13 +1275,22 @@ iterdpy (const char *inputfilename, int lineno, int start, /* l may be freed by remove_entry below. so save its contents */ next = l-next; tmp_auth = copyAuth(l-auth); - for (proto = proto_head; proto; proto = proto-next) { - if (match_auth_dpy (proto-auth, tmp_auth)) { - matched = True; - if (yfunc) { - status = (*yfunc) (inputfilename, lineno, - tmp_auth, data); - if (status 0) break; + + if ( match_authwild_dpy(tmp_auth, displayname) ) { + matched = True; + if (yfunc) { + status = (*yfunc) (inputfilename, lineno, + tmp_auth, data); + } + } else { + for (proto = proto_head; proto; proto = proto-next) { + if (match_auth_dpy (proto-auth, tmp_auth)) { + matched = True; + if (yfunc) { + status = (*yfunc) (inputfilename, lineno, + tmp_auth, data); + if (status 0) break; + } } } } ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2 xorg-gtest] process: add state enum and GetState()
On 08/13/2012 06:20 PM, Peter Hutterer wrote: Add a set of basic states to Process to allow callers to keep track of which state a process is in (as seen from the library). This simplifies code that needs to happen on certain conditions only, e.g. log file cleanup is only needed if the process was previously started. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- Changes to v1: - Move enum to Process class to better confine it - Check state on GetState(), update if it terminated on its own. - Check state on KillSelf(), return true if it already terminated anyway include/xorg/gtest/xorg-gtest-process.h | 17 + src/process.cpp | 25 + 2 files changed, 42 insertions(+) diff --git a/include/xorg/gtest/xorg-gtest-process.h b/include/xorg/gtest/xorg-gtest-process.h index 402be49..c4b2309 100644 --- a/include/xorg/gtest/xorg-gtest-process.h +++ b/include/xorg/gtest/xorg-gtest-process.h @@ -62,6 +62,16 @@ namespace testing { */ class Process { public: + /** +* Describes the state of a process. +*/ + enum State { + ERROR,/** An error has occured, state is now unknown */ + NONE, /** The process has not been started yet */ + RUNNING, /** The process has been started */ + TERMINATED, /** The process was terminated by this library */ + }; + /** * Helper function to adjust the environment of the current process. * @@ -179,6 +189,13 @@ class Process { */ pid_t Pid() const; + /** + * Return the state of the process. + * + * @return The current state of the process + */ + enum Process::State GetState(); + private: struct Private; std::auto_ptrPrivate d_; diff --git a/src/process.cpp b/src/process.cpp index 7df2b84..c976720 100644 --- a/src/process.cpp +++ b/src/process.cpp @@ -42,10 +42,26 @@ struct xorg::testing::Process::Private { pid_t pid; + enum State state; }; xorg::testing::Process::Process() : d_(new Private) { d_-pid = -1; + d_-state = NONE; +} + +enum xorg::testing::Process::State xorg::testing::Process::GetState() { + if (d_-state == RUNNING) { +int status; +int pid = waitpid(Pid(), status, WNOHANG); +if (pid == Pid()) { + if (WIFEXITED(status)) +d_-pid = -1; +d_-state = TERMINATED; This will mark the process as having terminated cleanly, even if it actually died due to an error. In fact, under the assumption that any process is meant to be indefinitely long, any exit first noticed here is an error. Should we set state here to ERROR instead? In the successful path, we will end up setting the state to TERMINATED inside KillSelf(). +} + } + + return d_-state; } void xorg::testing::Process::Start(const std::string program, const std::vectorstd::string argv) { @@ -55,6 +71,7 @@ void xorg::testing::Process::Start(const std::string program, const std::vector d_-pid = fork(); if (d_-pid == -1) { +d_-state = ERROR; throw std::runtime_error(Failed to fork child process); } else if (d_-pid == 0) { /* Child */ close(0); @@ -73,8 +90,11 @@ void xorg::testing::Process::Start(const std::string program, const std::vector execvp(program.c_str(), args[0]); +d_-state = ERROR; throw std::runtime_error(Failed to start process); } + + d_-state = RUNNING; } void xorg::testing::Process::Start(const std::string program, va_list args) { @@ -112,6 +132,9 @@ bool xorg::testing::Process::WaitForExit(unsigned int timeout) { bool xorg::testing::Process::KillSelf(int signal, unsigned int timeout) { bool wait_success = true; + if (GetState() == TERMINATED) +return true; + This would then be: State state = GetState(); if (state == TERMINATED) return true; if (state == ERROR) return false; if (d_-pid == -1) { return false; } else if (d_-pid == 0) { @@ -120,12 +143,14 @@ bool xorg::testing::Process::KillSelf(int signal, unsigned int timeout) { } else { /* Parent */ if (kill(d_-pid, signal) 0) { d_-pid = -1; + d_-state = ERROR; return false; } if (timeout 0) wait_success = WaitForExit(timeout); d_-pid = -1; } + d_-state = TERMINATED; return wait_success; } ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xorg-gtest 5/5] xserver: add RemoveLogFile()
On 08/13/2012 04:12 PM, Peter Hutterer wrote: On Mon, Aug 13, 2012 at 09:32:00AM -0700, Chase Douglas wrote: On 08/09/2012 10:38 PM, Peter Hutterer wrote: Simple unlink() call to the logfile in use. The log file is only removed if the server was started and terminated successfully. If it was never started or the startup failed for some reason, this function does nothing. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- include/xorg/gtest/xorg-gtest-xserver.h | 6 ++ src/xserver.cpp | 5 + 2 files changed, 11 insertions(+) diff --git a/include/xorg/gtest/xorg-gtest-xserver.h b/include/xorg/gtest/xorg-gtest-xserver.h index f3bda9b..33446a8 100644 --- a/include/xorg/gtest/xorg-gtest-xserver.h +++ b/include/xorg/gtest/xorg-gtest-xserver.h @@ -95,6 +95,12 @@ class XServer : public xorg::testing::Process { virtual bool Kill(unsigned int timeout = 0); /** + * Remove the log file used by this server. If the server was never + * started or the startup failed, this function does nothing. + */ +void RemoveLogFile(); + +/** * Waits until this server is ready to take connections. */ void WaitForConnections(void); diff --git a/src/xserver.cpp b/src/xserver.cpp index 86c8484..114c736 100644 --- a/src/xserver.cpp +++ b/src/xserver.cpp @@ -365,6 +365,11 @@ bool xorg::testing::XServer::Kill(unsigned int timeout) { return true; } +void xorg::testing::XServer::RemoveLogFile() { + if (GetState() == TERMINATED) +unlink(d_-options[-logfile].c_str()); +} + void xorg::testing::XServer::SetOption(const std::string key, const std::string value) { d_-options[key] = value; } I would prefer to call it something that gives a better idea that it is conditional on successful termination of the server. RemoveLogFile() sounds like a method that would *always* remove the log file. What about CleanUpLogFile()? tbh, I don't think there's much difference between the two names, and, had we both functions, I certainly couldn't tell the difference between the two without reading the documentation. The behaviour is stated in the API documentation and not removing what we didn't create is a good behaviour. If it's not any clearer to you, then maybe there isn't a perfect solution. I guess I'm ok with RemoveLogFile(). Or, you could just leave it up to the caller to call it only where it should be called. The caller can get the state just the same. Without the TERMINATED condition, this would simply be an unlink call, for any file the caller wants. If callers really just wanted to remove a file unconditionally, they can call unlink() themselves. True. After this discussion, I'm ready to give my tag: Reviewed-by: Chase Douglas chase.doug...@canonical.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xorg-gtest] process: document that va_args for Start() must end with zero-length string
On 08/13/2012 06:16 PM, Peter Hutterer wrote: Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- include/xorg/gtest/xorg-gtest-process.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/xorg/gtest/xorg-gtest-process.h b/include/xorg/gtest/xorg-gtest-process.h index 69b3b34..8cf60e3 100644 --- a/include/xorg/gtest/xorg-gtest-process.h +++ b/include/xorg/gtest/xorg-gtest-process.h @@ -123,7 +123,8 @@ class Process { * See 'man execvp' for further information on the variadic argument list. * * @param program The program to start. - * @param args Variadic list of arguments passed to the program. + * @param args Variadic list of arguments passed to the program. This list + * must end in a zero-length string (, not NULL). * * @throws std::runtime_error on failure. * @@ -135,7 +136,8 @@ class Process { /** * Starts a program as a child process. * - * Takes a variadic list of arguments passed to the program. + * Takes a variadic list of arguments passed to the program. This list + * must end in a zero-length string (, not NULL). * See 'man execvp' for further information on the variadic argument list. * * @param program The program to start. Hmmm... I wish we had though to use a NULL sentinel for the varargs version. We could have used the gcc sentinel function attribute to help warn people of bad usage. I suppose it's too late to change now that we've released it. Reviewed-by: Chase Douglas chase.doug...@canonical.com And pushed as commit 4b8f4dd2b2be2bb036f75403ef4cef31d280f70b. Thanks! ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] fb: reorder Bresenham error correction to avoid overshoot.
On Mon, Aug 13, 2012 at 1:57 PM, Keith Packard kei...@keithp.com wrote: Matt Turner matts...@gmail.com writes: From: Simon Schubert 2...@0x2c.org When fbBresSolid draws a line, it can happen that after the last pixel, the Bresenham error term overflows, and fbBresSolid paints another pixel before adjusting the error term. However, if this happens on the last pixel (len=0), this extra pixel might overshoot the boundary, and, in rare cases, lead to a segfault. Fix this issue by adjusting for the Bresenham error term before drawing the main pixel, not after. This looks like something that should land for 1.13, right? -- keith.pack...@intel.com Yeah, I think so. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modesetting] drmmode_display: add DRM_MODE_CONNECTOR_VIRTUAL to output_names
Added by a7331e5cb, since v3.2-rc1 Signed-off-by: Alon Levy al...@redhat.com --- src/drmmode_display.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/drmmode_display.c b/src/drmmode_display.c index 5e38265..e455de9 100644 --- a/src/drmmode_display.c +++ b/src/drmmode_display.c @@ -882,7 +882,8 @@ const char *output_names[] = { None, HDMI, HDMI, TV, - eDP + eDP, + Virtual, }; static void -- 1.7.11.2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xorg-gtest] process: document that va_args for Start() must end with zero-length string
On Tue, Aug 14, 2012 at 10:19:00AM -0700, Chase Douglas wrote: On 08/13/2012 06:16 PM, Peter Hutterer wrote: Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- include/xorg/gtest/xorg-gtest-process.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/xorg/gtest/xorg-gtest-process.h b/include/xorg/gtest/xorg-gtest-process.h index 69b3b34..8cf60e3 100644 --- a/include/xorg/gtest/xorg-gtest-process.h +++ b/include/xorg/gtest/xorg-gtest-process.h @@ -123,7 +123,8 @@ class Process { * See 'man execvp' for further information on the variadic argument list. * * @param program The program to start. - * @param args Variadic list of arguments passed to the program. + * @param args Variadic list of arguments passed to the program. This list + * must end in a zero-length string (, not NULL). * * @throws std::runtime_error on failure. * @@ -135,7 +136,8 @@ class Process { /** * Starts a program as a child process. * - * Takes a variadic list of arguments passed to the program. + * Takes a variadic list of arguments passed to the program. This list + * must end in a zero-length string (, not NULL). * See 'man execvp' for further information on the variadic argument list. * * @param program The program to start. Hmmm... I wish we had though to use a NULL sentinel for the varargs version. We could have used the gcc sentinel function attribute to help warn people of bad usage. I suppose it's too late to change now that we've released it. I disagree. We're only up to 0.4 and have few users only. Pretending we have a good and stable API already is optimistic at best, it's better to fix the things that are obviously (or at least reasonably :) broken. This isn't hard thing to fix either (I'll send patches out in a bit), so there really isn't an excuse for having a bad API, it'll just come and haunt us later. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] fb: reorder Bresenham error correction to avoid overshoot.
Matt Turner matts...@gmail.com writes: From: Simon Schubert 2...@0x2c.org When fbBresSolid draws a line, it can happen that after the last pixel, the Bresenham error term overflows, and fbBresSolid paints another pixel before adjusting the error term. However, if this happens on the last pixel (len=0), this extra pixel might overshoot the boundary, and, in rare cases, lead to a segfault. Fix this issue by adjusting for the Bresenham error term before drawing the main pixel, not after. Merged. c22c936..863d528 master - master -- keith.pack...@intel.com pgpnf1FGyKqJu.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 3/3] Kludge -- Call RandR screen before cleaning up xf86 crtcs
Dave Airlie airl...@gmail.com writes: Yeah its pretty kludgey but probably the best solution for now. Reviewed-by: Dave Airlie airl...@redhat.com All three of these are merged. 863d528..c0540b4 master - master -- keith.pack...@intel.com pgp8tjCWWcySx.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] dix: work around scaling issues during WarpPointer (#53037)
Peter Hutterer peter.hutte...@who-t.net writes: In WarpPointer calls, we get input in screen coordinates. They must be scaled to device coordinates, and then back to screen coordinates for screen crossing and root coordinates in events. The rounding errors introduced (and clipping in core/XI 1.x events) can lead to the actual position being different to the requested input coordinates. e.g. 200 scales to 199., truncated to 199 in the event. Would it be useful to do a bit of rounding in these conversions somewhere? -- keith.pack...@intel.com pgpV47L13C3L3.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] dix: work around scaling issues during WarpPointer (#53037)
On Tue, Aug 14, 2012 at 05:19:45PM -0700, Keith Packard wrote: Peter Hutterer peter.hutte...@who-t.net writes: In WarpPointer calls, we get input in screen coordinates. They must be scaled to device coordinates, and then back to screen coordinates for screen crossing and root coordinates in events. The rounding errors introduced (and clipping in core/XI 1.x events) can lead to the actual position being different to the requested input coordinates. e.g. 200 scales to 199., truncated to 199 in the event. Would it be useful to do a bit of rounding in these conversions somewhere? The only place you can round is after scaling back into the screen coordinate system and there's still a small chance of failure. It largely depends on the difference between screen coordinate system and device coordinate system. So the two options we have are: 1) round() and take the potential errors. This is the better choice for devices where round() gives more than a pixel difference since device and root coordinates will have less of a difference. 2) force the explicit pointer position. This will hurt more for devices that are off by more than one pixel, but won't show up by those within a pixel. Feel free to calculate what the difference in coordinate systems must be to favour one of the other :) Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Driver autoload/autodetection for platform devices
Hey, I'm looking at the latest code included to support platform devices, and platform bus, and I'm trying to understand how it can be used to dynamically autoload/autodetect the drivers available at the system. At my current use case, I'm trying to get the xserver to automatically load the xf86-video-omap driver in case it's available at the system, and I'm running at a Pandaboard. Currently to make the driver to load, you need to create a xorg.conf just to point out to xserver which driver to load, and as I know platform devices support was improved by Dave, I want to understand what would be the steps needed to avoid having the xorg config file at the system just to use the omap xorg driver. Looking at the latest platform related code included by Dave, this is what is happening at my current system: 1 - xf86platformProbe is called, which register the udev callback for xf86PlatformDeviceProbe, which is also executed as we have a a valid dri/card0 available at the system (linux 3.4, using omap drm); 2 - The platform device for /dev/dri/card0 is registered by xf86_add_platform_device, setting the correct attributes but setting pdev as NULL; 3 - listPossibleVideoDrivers calls xf86PlatformMatchDriver, but as pdev is still null, it doesn't call xf86MatchDriverFromFiles; 4 - Xorg then loads fbdev and moves on; As we don't have a common bus to probe for devices, one way would be to also depend on xf86MatchDriverFromFiles, but for that we'd need to make sure we're probing the correct device/vendor id from the platform device. I don't know much about the details on how this could be done with drm/kms, so that's why I first wanted to know if that would be a really a valid path. Is there any other way where we could change at Xorg to be able to dynamically detect/load the platform (without a pci bus to probe) specific drivers? Thanks, -- Ricardo Salveti de Araujo ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Driver autoload/autodetection for platform devices
On Tue, Aug 14, 2012 at 10:45 PM, Ricardo Salveti ricardo.salv...@linaro.org wrote: Hey, I'm looking at the latest code included to support platform devices, and platform bus, and I'm trying to understand how it can be used to dynamically autoload/autodetect the drivers available at the system. At my current use case, I'm trying to get the xserver to automatically load the xf86-video-omap driver in case it's available at the system, and I'm running at a Pandaboard. Currently to make the driver to load, you need to create a xorg.conf just to point out to xserver which driver to load, and as I know platform devices support was improved by Dave, I want to understand what would be the steps needed to avoid having the xorg config file at the system just to use the omap xorg driver. Looking at the latest platform related code included by Dave, this is what is happening at my current system: 1 - xf86platformProbe is called, which register the udev callback for xf86PlatformDeviceProbe, which is also executed as we have a a valid dri/card0 available at the system (linux 3.4, using omap drm); 2 - The platform device for /dev/dri/card0 is registered by xf86_add_platform_device, setting the correct attributes but setting pdev as NULL; 3 - listPossibleVideoDrivers calls xf86PlatformMatchDriver, but as pdev is still null, it doesn't call xf86MatchDriverFromFiles; 4 - Xorg then loads fbdev and moves on; As we don't have a common bus to probe for devices, one way would be to also depend on xf86MatchDriverFromFiles, but for that we'd need to make sure we're probing the correct device/vendor id from the platform device. I don't know much about the details on how this could be done with drm/kms, so that's why I first wanted to know if that would be a really a valid path. Is there any other way where we could change at Xorg to be able to dynamically detect/load the platform (without a pci bus to probe) specific drivers? Also, another issue I just noticed, is that even if we get the autoload/autodetect at the Xorg side, it'll still load fbdev even after omap is loaded (loading 2 different screens). Looking at the code, it seems that this happens because there's no way to control if the slot was claimed, because the omap driver uses xf86ClaimNoSlot instead of xf86ClaimPlatformSlot (not yet public, but would probably be the one to be called). So I believe another change that would be needed is to export xf86ClaimPlatformSlot as well, unless there's another way to control tell fbdev not to load it's own driver. Cheers, -- Ricardo Salveti de Araujo ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel