[PATCH] drivers/video/udlfb bind framebuffer to interface.

[PATCH] drivers/video/udlfb bind framebuffer to interface.

[bernie]

From: Kay Sievers <kay.sievers@vrfy.org>

Udlfb has been binding the framebuffer device to its parent, which
isn't correct and causes confusion with operations like udev remove.

Coming plug and play multiseat support is dependent on this fix.

Signed-off-by: Bernie Thompson <bernie@plugable.com>
---
 drivers/video/udlfb.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 816a4fd..c6584c9 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1549,7 +1549,7 @@ static int dlfb_usb_probe(struct usb_interface *interface,
 	/* We don't register a new USB class. Our client interface is fbdev */
 
 	/* allocates framebuffer driver structure, not framebuffer memory */
-	info = framebuffer_alloc(0, &usbdev->dev);
+	info = framebuffer_alloc(0, &interface->dev);
 	if (!info) {
 		retval = -ENOMEM;
 		pr_err("framebuffer_alloc failed\n");
-- 
1.7.4.1

Re: [PATCH] drivers/video/udlfb bind framebuffer to interface.

[JinGoo Han]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1840 bytes --]

Hi, Bernie Thompson.
> -----Original Message-----
> From: linux-fbdev-owner@vger.kernel.org [mailto:linux-fbdev-
> owner@vger.kernel.org] On Behalf Of bernie@plugable.com
> Sent: Wednesday, July 06, 2011 9:04 AM
> To: linux-fbdev@vger.kernel.org
> Cc: lethal@linux-sh.org; Kay Sievers; Bernie Thompson
> Subject: [PATCH] drivers/video/udlfb bind framebuffer to interface.
> 
> From: Kay Sievers <kay.sievers@vrfy.org>
> 
> Udlfb has been binding the framebuffer device to its parent, which
> isn't correct and causes confusion with operations like udev remove.
> 
> Coming plug and play multiseat support is dependent on this fix.
> 
> Signed-off-by: Bernie Thompson <bernie@plugable.com>
This patch author seems to be Kay Sievers <kay.sievers@vrfy.org>.
Should you add Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> ?
> ---
>  drivers/video/udlfb.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
> index 816a4fd..c6584c9 100644
> --- a/drivers/video/udlfb.c
> +++ b/drivers/video/udlfb.c
> @@ -1549,7 +1549,7 @@ static int dlfb_usb_probe(struct usb_interface
> *interface,
>  	/* We don't register a new USB class. Our client interface is fbdev
> */
> 
>  	/* allocates framebuffer driver structure, not framebuffer memory
> */
> -	info = framebuffer_alloc(0, &usbdev->dev);
> +	info = framebuffer_alloc(0, &interface->dev);
>  	if (!info) {
>  		retval = -ENOMEM;
>  		pr_err("framebuffer_alloc failed\n");
> --
> 1.7.4.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ýöÝzÿâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

Re: [PATCH] drivers/video/udlfb bind framebuffer to interface.

[Paul Mundt]

On Tue, Jul 05, 2011 at 05:04:11PM -0700, bernie@plugable.com wrote:
> Udlfb has been binding the framebuffer device to its parent, which
> isn't correct and causes confusion with operations like udev remove.
> 
> Coming plug and play multiseat support is dependent on this fix.
> 
> Signed-off-by: Bernie Thompson <bernie@plugable.com>

On Sun, Jul 10, 2011 at 12:30:00AM -0700, bernie@plugable.com wrote:
> Match udlfb only against vendor-specific class (e.g. only DisplayLink
> graphics, not composite standard audio class interfaces). This enables
> compatibility with composite graphics+audio devices (e.g. HDMI).
> 
> Match udlfb only against compatible subclass 0 and protocol 0 chips.
> DisplayLink's USB 3.0 generation chips increment these values
> to signal that they have a incompatible protocol, preventing udlfb
> from erroneously matching to hardware it does not support.
> 
> Tested to confirm proper behavior on both USB 2.0 and USB 3.0
> generation devices.
> 
> Reported-by: Andrew Kephart <akephart@akephart.org>
> Signed-off-by: Bernie Thompson <bernie@plugable.com>

Both queued for 3.0, thanks.