Re: [Nouveau] nouveau preventing shutdown after suspend-resume

[poma]

On 17.02.2017 18:06, Ilia Mirkin wrote:
> On Fri, Feb 17, 2017 at 11:22 AM, João Paulo Rechi Vita
>  wrote:
>> Hello Ilia,
>>
>> On 17 February 2017 at 11:14, Ilia Mirkin  wrote:
>>> On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
>>>  wrote:
 I'm happy to file
 a bugzilla entry and provide any other needed information or help with
 testing. Are nouveau bugs tracked on bugs.kernel.org or the fdo
 bugzilla?
>>>
>>> Nouveau bugs are tracked on the fdo bugzilla. It would appear that
>>> you're using a 4.8 kernel. Do issues persist with a 4.10 kernel? I'm
>>> thinking of upstream commit cae9ff036ee, but it's likely that there
>>> have also been others I'm not thinking of.
>>>
>>
>> Yes, although the logs I have pasted were indeed collected using a 4.8
>> kernel, the problem persists with a recent Linus' tree (v4.10-rc8 + a
>> couple of commits) which contains cae9ff036ee.
> 
> You should file a bug with all the relevant info. BTW, odd that the
> device is reported as 179c. 1780-17bf isn't allocated to anything.
> There *is* a 139c device, "GM107M [GeForce 940M]", but that would
> imply there's an extra 0x0400 bit set.
> 

$ curl -s ftp://download.nvidia.com/XFree86/Linux-x86/375.39/README/README.txt 
| grep -i 179c 
GeForce 940MX 179C   E


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/udl: make control msg static const. (v2)

[poma]

On 08.11.2016 07:47, Dave Airlie wrote:
> From: Dave Airlie 
> 
> Thou shall not send control msg from the stack,
> does that mean I can send it from the RO memory area?
> 
> and it looks like the answer is no, so here's
> v2 which kmemdups.
> 
> Reported-by: poma
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/udl/udl_main.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
> index 29f0207..873f010 100644
> --- a/drivers/gpu/drm/udl/udl_main.c
> +++ b/drivers/gpu/drm/udl/udl_main.c
> @@ -98,17 +98,23 @@ static int udl_parse_vendor_descriptor(struct drm_device 
> *dev,
>  static int udl_select_std_channel(struct udl_device *udl)
>  {
>   int ret;
> - u8 set_def_chn[] = {0x57, 0xCD, 0xDC, 0xA7,
> - 0x1C, 0x88, 0x5E, 0x15,
> - 0x60, 0xFE, 0xC6, 0x97,
> - 0x16, 0x3D, 0x47, 0xF2};
> + static const u8 set_def_chn[] = {0x57, 0xCD, 0xDC, 0xA7,
> +  0x1C, 0x88, 0x5E, 0x15,
> +  0x60, 0xFE, 0xC6, 0x97,
> +  0x16, 0x3D, 0x47, 0xF2};
> + void *sendbuf;
> +
> + sendbuf = kmemdup(set_def_chn, sizeof(set_def_chn), GFP_KERNEL);
> + if (!sendbuf)
> + return -ENOMEM;
>  
>   ret = usb_control_msg(udl->udev,
> usb_sndctrlpipe(udl->udev, 0),
> NR_USB_REQUEST_CHANNEL,
> (USB_DIR_OUT | USB_TYPE_VENDOR), 0, 0,
> -   set_def_chn, sizeof(set_def_chn),
> +   sendbuf, sizeof(set_def_chn),
>     USB_CTRL_SET_TIMEOUT);
> + kfree(sendbuf);
>   return ret < 0 ? ret : 0;
>  }
>  
> 

v2 is OK.
Tested-by: poma 

[PATCH] drm/udl: make control msg static const.

[poma]

On 08.11.2016 07:39, Dave Airlie wrote:
> From: Dave Airlie 
> 
> Thou shall not send control msg from the stack,
> does that mean I can send it from the RO memory area?
> 
> Reported-by: poma
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/udl/udl_main.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
> index 29f0207..0798bcc 100644
> --- a/drivers/gpu/drm/udl/udl_main.c
> +++ b/drivers/gpu/drm/udl/udl_main.c
> @@ -98,10 +98,10 @@ static int udl_parse_vendor_descriptor(struct drm_device 
> *dev,
>  static int udl_select_std_channel(struct udl_device *udl)
>  {
>   int ret;
> - u8 set_def_chn[] = {0x57, 0xCD, 0xDC, 0xA7,
> - 0x1C, 0x88, 0x5E, 0x15,
> - 0x60, 0xFE, 0xC6, 0x97,
> - 0x16, 0x3D, 0x47, 0xF2};
> + static const u8 set_def_chn[] = {0x57, 0xCD, 0xDC, 0xA7,
> +  0x1C, 0x88, 0x5E, 0x15,
> +  0x60, 0xFE, 0xC6, 0x97,
> +  0x16, 0x3D, 0x47, 0xF2};
>  
>   ret = usb_control_msg(udl->udev,
> usb_sndctrlpipe(udl->udev, 0),
> 


There is a compile time WARN:

$ make drivers/gpu/drm/udl/udl.ko
...
  CC [M]  drivers/gpu/drm/udl/udl_fb.o
drivers/gpu/drm/udl/udl_main.c: In function ‘udl_select_std_channel’:
drivers/gpu/drm/udl/udl_main.c:110:10: warning: passing argument 7 of 
‘usb_control_msg’ discards ‘const’ qualifier from pointer target type 
[-Wdiscarded-qualifiers]
  set_def_chn, sizeof(set_def_chn),
  ^~~
In file included from drivers/gpu/drm/udl/udl_drv.h:17:0,
 from drivers/gpu/drm/udl/udl_main.c:14:
./include/linux/usb.h:1685:12: note: expected ‘void *’ but argument is of 
type ‘const u8 * {aka const unsigned char *}’
 extern int usb_control_msg(struct usb_device *dev, unsigned int pipe,
^~~
  CC [M]  drivers/gpu/drm/udl/udl_transfer.o
  CC [M]  drivers/gpu/drm/udl/udl_gem.o
  CC [M]  drivers/gpu/drm/udl/udl_dmabuf.o
  LD [M]  drivers/gpu/drm/udl/udl.o
  MODPOST 1 modules
  CC  drivers/gpu/drm/udl/udl.mod.o
  LD [M]  drivers/gpu/drm/udl/udl.ko


Also there is a flood of waiting for request block:

$ dmesg | grep -P '(?=.*drm)(?=.*urb)'
[   72.482211] [drm] wait for urb interrupted: ffc2 available: 0
[   75.552227] [drm] wait for urb interrupted: ffc2 available: 0
[   76.576146] [drm] wait for urb interrupted: ffc2 available: 0
...
[  100.192153] [drm] wait for urb interrupted: ffc2 available: 0
[  101.216166] [drm] wait for urb interrupted: ffc2 available: 0
[  102.240141] [drm] wait for urb interrupted: ffc2 available: 0
...
[  200.416146] [drm] wait for urb interrupted: ffc2 available: 0
[  201.440208] [drm] wait for urb interrupted: ffc2 available: 0
[  204.384162] [drm] wait for urb interrupted: ffc2 available: 0
...
[  300.448151] [drm] wait for urb interrupted: ffc2 available: 0
[  301.920166] [drm] wait for urb interrupted: ffc2 available: 0
[  304.416147] [drm] wait for urb interrupted: ffc2 available: 0
...
[  370.016157] [drm] wait for urb interrupted: ffc2 available: 0
...


And finally,
Master Chef's special, the machine is KO'd due to trying out a module reload.

[PATCH v2] drm/udl: Ensure channel is selected before using the device.

[poma]

On 23.08.2016 07:57, Daniel Vetter wrote:
> On Mon, Aug 22, 2016 at 11:17:34PM +0100, Jamie Lentin wrote:
>> Lift configuration command from udlfb. This appears to be essential for
>> at least a Rextron VCUD-60, without which no URB communication occurs.
>>
>> Signed-off-by: Jamie Lentin 
>> ---
>> udl_encoder_commit() is too late to do this set up in it seems. This
>> setup doesn't need to be performed again after a suspend, although this
>> is somewhat academic until I send the patch adding suspend and resume
>> functions.
>>
>> Tested with a Rextron VCUD-60 attached to a Thinkpad X201s on Linux 4.7.0
> 
> Applied to drm-misc, thanks.
> -Daniel
> 
>>
>> Cheers,
>> ---
>>  drivers/gpu/drm/udl/udl_main.c | 25 +
>>  1 file changed, 25 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
>> index 33dbfb2..29f0207 100644
>> --- a/drivers/gpu/drm/udl/udl_main.c
>> +++ b/drivers/gpu/drm/udl/udl_main.c
>> @@ -16,6 +16,8 @@
>>  /* -BULK_SIZE as per usb-skeleton. Can we get full page and avoid overhead? 
>> */
>>  #define BULK_SIZE 512
>>  
>> +#define NR_USB_REQUEST_CHANNEL 0x12
>> +
>>  #define MAX_TRANSFER (PAGE_SIZE*16 - BULK_SIZE)
>>  #define WRITES_IN_FLIGHT (4)
>>  #define MAX_VENDOR_DESCRIPTOR_SIZE 256
>> @@ -90,6 +92,26 @@ success:
>>  return true;
>>  }
>>  
>> +/*
>> + * Need to ensure a channel is selected before submitting URBs
>> + */
>> +static int udl_select_std_channel(struct udl_device *udl)
>> +{
>> +int ret;
>> +u8 set_def_chn[] = {0x57, 0xCD, 0xDC, 0xA7,
>> +0x1C, 0x88, 0x5E, 0x15,
>> +0x60, 0xFE, 0xC6, 0x97,
>> +0x16, 0x3D, 0x47, 0xF2};
>> +
>> +ret = usb_control_msg(udl->udev,
>> +  usb_sndctrlpipe(udl->udev, 0),
>> +  NR_USB_REQUEST_CHANNEL,
>> +  (USB_DIR_OUT | USB_TYPE_VENDOR), 0, 0,
>> +  set_def_chn, sizeof(set_def_chn),
>> +  USB_CTRL_SET_TIMEOUT);
>> +return ret < 0 ? ret : 0;
>> +}
>> +
>>  static void udl_release_urb_work(struct work_struct *work)
>>  {
>>  struct urb_node *unode = container_of(work, struct urb_node,
>> @@ -301,6 +323,9 @@ int udl_driver_load(struct drm_device *dev, unsigned 
>> long flags)
>>  goto err;
>>  }
>>  
>> +if (udl_select_std_channel(udl))
>> +DRM_ERROR("Selecting channel failed\n");
>> +
>>  if (!udl_alloc_urb_list(dev, WRITES_IN_FLIGHT, MAX_TRANSFER)) {
>>  DRM_ERROR("udl_alloc_urb_list failed\n");
>>  goto err;
>> -- 
>> 2.8.1
>>
> 

It doesn't breaks the device, however under the hood it is boiling,

[ cut here ]
WARNING: CPU: 0 PID: 381 at drivers/usb/core/hcd.c:1584 
usb_hcd_map_urb_for_dma+0x49f/0x770
transfer buffer not dma capable
Modules linked in: ... udl(+) ... drm_kms_helper ... drm ...
CPU: 0 PID: 381 Comm: systemd-udevd Not tainted 
4.9.0-0.rc4.git0.1.fc26.x86_64+debug #1
...
Call Trace:
 [] dump_stack+0x86/0xc3
 [] __warn+0xcb/0xf0
 [] warn_slowpath_fmt+0x5f/0x80
 [] ? debug_dma_mapping_error+0x7b/0x90
 [] usb_hcd_map_urb_for_dma+0x49f/0x770
 [] ? trace_hardirqs_on_caller+0xf5/0x1b0
 [] usb_hcd_submit_urb+0x34d/0xb50
 [] ? mark_held_locks+0x76/0xa0
 [] ? __raw_spin_lock_init+0x21/0x60
 [] ? trace_hardirqs_on_caller+0xf5/0x1b0
 [] usb_submit_urb+0x2f4/0x560
 [] ? lockdep_init_map+0x61/0x210
 [] usb_start_wait_urb+0x74/0x180
 [] usb_control_msg+0xdc/0x120
 [] udl_driver_load+0x141/0x590 [udl]
 [] ? trace_hardirqs_on_caller+0xd1/0x1b0
 [] drm_dev_register+0xa9/0xd0 [drm]
 [] udl_usb_probe+0x42/0x90 [udl]
 [] usb_probe_interface+0x15f/0x2d0
 [] driver_probe_device+0x223/0x430
 [] __driver_attach+0xe3/0xf0
 [] ? driver_probe_device+0x430/0x430
 [] bus_for_each_dev+0x73/0xc0
 [] driver_attach+0x1e/0x20
 [] bus_add_driver+0x173/0x270
 [] driver_register+0x60/0xe0
 [] usb_register_driver+0xaa/0x160
 [] ? 0xc089a000
 [] udl_driver_init+0x1e/0x1000 [udl]
 [] do_one_initcall+0x50/0x180
 [] ? rcu_read_lock_sched_held+0x45/0x80
 [] ? kmem_cache_alloc_trace+0x277/0x2d0
 [] ? do_init_module+0x27/0x1f1
 [] do_init_module+0x5f/0x1f1
 [] load_module+0x2401/0x2b40
 [] ? __symbol_put+0x70/0x70
 [] ? sched_clock_cpu+0x90/0xc0
 [] SYSC_init_module+0x19b/0x1c0
 [] SyS_init_module+0xe/0x10
 [] do_syscall_64+0x6c/0x1f0
 [] entry_SYSCALL64_slow_path+0x25/0x25
---[ end trace 1fa5e22a0dcf62da ]---
[drm:udl_driver_load [udl]] *ERROR* Selecting channel failed
udl 1-2:1.0: fb1: udldrmfb frame buffer device
[drm] Initialized udl on minor 1
usbcore: registered new interface driver udl


Is this expected WARN?


Ref.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/udl?id=d1c151dc
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/core/hcd.c?id=refs/tags/v4.9-rc4#n1584

[PATCH] drm/udl: Fix for the X server screen update v2

[poma]

On 19.09.2016 23:12, Daniel Vetter wrote:
> On Mon, Sep 19, 2016 at 8:27 PM, poma  wrote:
>> @@ -122,14 +126,14 @@ int udl_handle_damage(struct udl_framebuffer *fb, int 
>> x, int y,
>> return 0;
>> cmd = urb->transfer_buffer;
>>
>> -   for (i = y; i < height ; i++) {
>> +   for (i = y; i <= y2 ; i++) {
> 
> I think a simpler fix (which retains Noralf's nice cleanup would be to
> change the loop condition to i < y + height. At least that seems to be
> the underlying bug. Can you pls test that and then submit either that
> one-liner (if it works) or your original patch (it's missing the
> signed-off-by right now, so can't be merged as-is)? Either one has my
> r-b (preemptive since I'm travelling).
> 
> Thanks, Daniel
> 

Feel free to (re)send patch v3, whenever you can.
After all, the idea is yours.

Respect

[PATCH] drm/udl: Fix for the X server screen update v3

[poma]

On 21.09.2016 13:33, David Herrmann wrote:
> Hi
> 
> On Wed, Sep 21, 2016 at 1:19 PM, poma  wrote:
>> On 21.09.2016 09:34, David Herrmann wrote:
>>> Hi
>>>
>>> On Wed, Sep 21, 2016 at 6:47 AM, poma  wrote:
>>>> Within X server, on top of DisplayLink GPU USB2.0 device,
>>>> screen content is not refreshed i.e. updated.
>>>>
>>>> This fixes commit:
>>>>
>>>> - e375882406d0cc24030746638592004755ed4ae0
>>>>   "drm/udl: Use drm_fb_helper deferred_io support"
>>>>
>>>> Thanks Noralf and Daniel for the comments.
>>>>
>>>> Tested-by: poma 
>>>
>>> Can you provide your Signed-off-by: line?
>>>
>>> Reviewed-by: David Herrmann 
>>>
>>> Thanks
>>> David
>>>
>>
>> S-o-b should be performed by the actual kernel developer.
>> R-b & T-b, I've already written.
> 
> The author of a patch must provide the S-o-b (see
> Documentation/SubmittingPatches if you want details). So simply reply
> with a "S-o-b: foo " line to this mail. And please include it in
> all patches you submit (preferably use `git commit --sign-off`).
> 
> Thanks
> David
> 

Patches are nothing but direct suggestions from Noralf and Daniel.
I wrote a patch to show what is actually tested, tested successfully,
but I'm not the author of these corrections.

[PATCH] drm/udl: Fix for the X server screen update v3

[poma]

On 21.09.2016 09:34, David Herrmann wrote:
> Hi
> 
> On Wed, Sep 21, 2016 at 6:47 AM, poma  wrote:
>> Within X server, on top of DisplayLink GPU USB2.0 device,
>> screen content is not refreshed i.e. updated.
>>
>> This fixes commit:
>>
>> - e375882406d0cc24030746638592004755ed4ae0
>>   "drm/udl: Use drm_fb_helper deferred_io support"
>>
>> Thanks Noralf and Daniel for the comments.
>>
>> Tested-by: poma 
> 
> Can you provide your Signed-off-by: line?
> 
> Reviewed-by: David Herrmann 
> 
> Thanks
> David
> 

S-o-b should be performed by the actual kernel developer.
R-b & T-b, I've already written.

[PATCH] drm/udl: Fix for the X server screen update v3

[poma]

Within X server, on top of DisplayLink GPU USB2.0 device,
screen content is not refreshed i.e. updated.

This fixes commit:

- e375882406d0cc24030746638592004755ed4ae0
  "drm/udl: Use drm_fb_helper deferred_io support"

Thanks Noralf and Daniel for the comments.

Tested-by: poma 
---
 drivers/gpu/drm/udl/udl_fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index d5df555..cc2daba 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -122,7 +122,7 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
return 0;
cmd = urb->transfer_buffer;

-   for (i = y; i < height ; i++) {
+   for (i = y; i < y + height ; i++) {
const int line_offset = fb->base.pitches[0] * i;
const int byte_offset = line_offset + (x * bpp);
const int dev_byte_offset = (fb->base.width * bpp * i) + (x * 
bpp);
-- 
2.7.4

[PATCH] drm/udl: Fix for the X server screen update v2

[poma]

Fix for DisplayLink GPU USB2.0 device X server screen update

Within X server on top of DisplayLink GPU USB2.0 device,
screen content is not refreshed i.e. updated,
which is the most basic functionality of the screen.

This partially (udl_handle_damage()) reverts commit:

- e375882406d0cc24030746638592004755ed4ae0
  "drm/udl: Use drm_fb_helper deferred_io support"

Thanks Noralf for the comments.

Reported and
Tested-by: poma 
---
 drivers/gpu/drm/udl/udl_fb.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index d5df555..05ab114 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -90,6 +90,7 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, int 
y,
struct urb *urb;
int aligned_x;
int bpp = (fb->base.bits_per_pixel / 8);
+   int x2, y2;

if (!fb->active_16)
return 0;
@@ -115,6 +116,9 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
(y + height > fb->base.height))
return -EINVAL;

+   x2 = x + width - 1;
+   y2 = y + height - 1;
+
start_cycles = get_cycles();

urb = udl_get_urb(dev);
@@ -122,14 +126,14 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
return 0;
cmd = urb->transfer_buffer;

-   for (i = y; i < height ; i++) {
+   for (i = y; i <= y2 ; i++) {
const int line_offset = fb->base.pitches[0] * i;
const int byte_offset = line_offset + (x * bpp);
const int dev_byte_offset = (fb->base.width * bpp * i) + (x * 
bpp);
if (udl_render_hline(dev, bpp, ,
 (char *) fb->obj->vmapping,
 , byte_offset, dev_byte_offset,
-width * bpp,
+(x2 - x + 1) * bpp,
 _identical, _sent))
goto error;
}
-- 
2.7.4

[PATCH] drm/udl: Fix for the X server screen update

[poma]

On 18.09.2016 19:42, Noralf Trønnes wrote:
> 
> Den 18.09.2016 15:48, skrev poma:
>> Fix for DisplayLink GPU USB2.0 device X server screen update
>>
>> Within X server on top of DisplayLink GPU USB2.0 device,
>> screen content is not refreshed i.e. updated,
>> which is the most basic functionality of the screen.
>>
>> This partially (udl_handle_damage()) reverts commit:
>>
>> - e375882406d0cc24030746638592004755ed4ae0
>>"drm/udl: Use drm_fb_helper deferred_io support"
>>
>> Thanks Noralf for the tip.
>>
>> $ modinfo udl
>> filename:   /lib/modules/4.7.4-234.fc24.x86_64/updates/udl.ko
>> license:GPL
>> alias:  usb:v17E9p*d*dc*dsc*dp*icFFisc00ip00in*
>> depends:
>> intree: Y
>> vermagic:   4.7.4-234.fc24.x86_64 SMP mod_unload
>> parm:   fb_bpp:int
>> parm:   fb_defio:int
>>
>> $ dmesg | grep udl
>> [   41.888469] udl: module verification failed: signature and/or required 
>> key missing - tainting kernel
>> [   42.156988] udl 1-2:1.0: fb1: udldrmfb frame buffer device
>> [   42.158940] [drm] Initialized udl on minor 1
>> [   42.159676] usbcore: registered new interface driver udl
>>
>> $ grep udl /var/log/Xorg.0.log
>> [71.194] (**) |   |-->Device "udl0"
>>
>> Tested-by: poma 
>> ---
>>   drivers/gpu/drm/udl/udl_drv.h |  2 ++
>>   drivers/gpu/drm/udl/udl_fb.c  | 39 +--
>>   2 files changed, 39 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
>> index 0b03d34..4a064ef 100644
>> --- a/drivers/gpu/drm/udl/udl_drv.h
>> +++ b/drivers/gpu/drm/udl/udl_drv.h
>> @@ -81,6 +81,8 @@ struct udl_framebuffer {
>>  struct drm_framebuffer base;
>>  struct udl_gem_object *obj;
>>  bool active_16; /* active on the 16-bit channel */
>> +int x1, y1, x2, y2; /* dirty rect */
>> +spinlock_t dirty_lock;
>>   };
>>   
>>   #define to_udl_fb(x) container_of(x, struct udl_framebuffer, base)
>> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
>> index d5df555..b2b42d2 100644
>> --- a/drivers/gpu/drm/udl/udl_fb.c
>> +++ b/drivers/gpu/drm/udl/udl_fb.c
>> @@ -90,6 +90,9 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
>> int y,
>>  struct urb *urb;
>>  int aligned_x;
>>  int bpp = (fb->base.bits_per_pixel / 8);
>> +int x2, y2;
>> +bool store_for_later = false;
>> +unsigned long flags;
>>   
>>  if (!fb->active_16)
>>  return 0;
>> @@ -115,6 +118,38 @@ int udl_handle_damage(struct udl_framebuffer *fb, int 
>> x, int y,
>>  (y + height > fb->base.height))
>>  return -EINVAL;
>>   
>> +/* if we are in atomic just store the info
>> +   can't test inside spin lock */
>> +if (in_atomic())
>> +store_for_later = true;
>> +
>> +x2 = x + width - 1;
>> +y2 = y + height - 1;
>> +
>> +spin_lock_irqsave(>dirty_lock, flags);
> 
> You can drop the spinlock and store_for_later since it always runs in
> process context.
> Which means that there's no need to store x1/x2/y1/y2 in fb.
> 
>> +
>> +if (fb->y1 < y)
>> +y = fb->y1;
>> +if (fb->y2 > y2)
>> +y2 = fb->y2;
>> +if (fb->x1 < x)
>> +x = fb->x1;
>> +if (fb->x2 > x2)
>> +x2 = fb->x2;
>> +
>> +if (store_for_later) {
>> +fb->x1 = x;
>> +fb->x2 = x2;
>> +fb->y1 = y;
>> +fb->y2 = y2;
>> +spin_unlock_irqrestore(>dirty_lock, flags);
>> +return 0;
>> +}
>> +
>> +fb->x1 = fb->y1 = INT_MAX;
>> +fb->x2 = fb->y2 = 0;
>> +
>> +spin_unlock_irqrestore(>dirty_lock, flags);
>>  start_cycles = get_cycles();
>>   
>>  urb = udl_get_urb(dev);
>> @@ -122,14 +157,14 @@ int udl_handle_damage(struct udl_framebuffer *fb, int 
>> x, int y,
>>  return 0;
>>  cmd = urb->transfer_buffer;
>>   
>> -for (i = y; i < height ; i++) {
>> +for (i = y; i <= y2 ; i++) {
>>  const int line_offset = fb->base.pitches[0] * i;
>>  const int byte_offset = line_offset + (x * bpp);
>>  c

[PATCH] drm/udl: Fix for the X server screen update

[poma]

Fix for DisplayLink GPU USB2.0 device X server screen update

Within X server on top of DisplayLink GPU USB2.0 device,
screen content is not refreshed i.e. updated,
which is the most basic functionality of the screen.

This partially (udl_handle_damage()) reverts commit:

- e375882406d0cc24030746638592004755ed4ae0
  "drm/udl: Use drm_fb_helper deferred_io support"

Thanks Noralf for the tip.

$ modinfo udl
filename:   /lib/modules/4.7.4-234.fc24.x86_64/updates/udl.ko
license:GPL
alias:  usb:v17E9p*d*dc*dsc*dp*icFFisc00ip00in*
depends:
intree: Y
vermagic:   4.7.4-234.fc24.x86_64 SMP mod_unload 
parm:   fb_bpp:int
parm:   fb_defio:int

$ dmesg | grep udl
[   41.888469] udl: module verification failed: signature and/or required key 
missing - tainting kernel
[   42.156988] udl 1-2:1.0: fb1: udldrmfb frame buffer device
[   42.158940] [drm] Initialized udl on minor 1
[   42.159676] usbcore: registered new interface driver udl

$ grep udl /var/log/Xorg.0.log
[71.194] (**) |   |-->Device "udl0"

Tested-by: poma 
---
 drivers/gpu/drm/udl/udl_drv.h |  2 ++
 drivers/gpu/drm/udl/udl_fb.c  | 39 +--
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 0b03d34..4a064ef 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -81,6 +81,8 @@ struct udl_framebuffer {
struct drm_framebuffer base;
struct udl_gem_object *obj;
bool active_16; /* active on the 16-bit channel */
+   int x1, y1, x2, y2; /* dirty rect */
+   spinlock_t dirty_lock;
 };

 #define to_udl_fb(x) container_of(x, struct udl_framebuffer, base)
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index d5df555..b2b42d2 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -90,6 +90,9 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, int 
y,
struct urb *urb;
int aligned_x;
int bpp = (fb->base.bits_per_pixel / 8);
+   int x2, y2;
+   bool store_for_later = false;
+   unsigned long flags;

if (!fb->active_16)
return 0;
@@ -115,6 +118,38 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
(y + height > fb->base.height))
return -EINVAL;

+   /* if we are in atomic just store the info
+  can't test inside spin lock */
+   if (in_atomic())
+   store_for_later = true;
+
+   x2 = x + width - 1;
+   y2 = y + height - 1;
+
+   spin_lock_irqsave(>dirty_lock, flags);
+
+   if (fb->y1 < y)
+   y = fb->y1;
+   if (fb->y2 > y2)
+   y2 = fb->y2;
+   if (fb->x1 < x)
+   x = fb->x1;
+   if (fb->x2 > x2)
+   x2 = fb->x2;
+
+   if (store_for_later) {
+   fb->x1 = x;
+   fb->x2 = x2;
+   fb->y1 = y;
+   fb->y2 = y2;
+   spin_unlock_irqrestore(>dirty_lock, flags);
+   return 0;
+   }
+
+   fb->x1 = fb->y1 = INT_MAX;
+   fb->x2 = fb->y2 = 0;
+
+   spin_unlock_irqrestore(>dirty_lock, flags);
start_cycles = get_cycles();

urb = udl_get_urb(dev);
@@ -122,14 +157,14 @@ int udl_handle_damage(struct udl_framebuffer *fb, int x, 
int y,
return 0;
cmd = urb->transfer_buffer;

-   for (i = y; i < height ; i++) {
+   for (i = y; i <= y2 ; i++) {
const int line_offset = fb->base.pitches[0] * i;
const int byte_offset = line_offset + (x * bpp);
const int dev_byte_offset = (fb->base.width * bpp * i) + (x * 
bpp);
if (udl_render_hline(dev, bpp, ,
 (char *) fb->obj->vmapping,
 , byte_offset, dev_byte_offset,
-width * bpp,
+(x2 - x + 1) * bpp,
 _identical, _sent))
goto error;
}
-- 
2.7.4

UDL: screen update breakage

[poma]

https://bugzilla.redhat.com/show_bug.cgi?id=1375566

Guys,
do you use such a device - DisplayLink GPU USB2.0 ?

[PATCH 04/13] drm/udl: Use unlocked gem unreferencing

[poma]

On 30.03.2016 11:40, Daniel Vetter wrote:
> For drm_gem_object_unreference callers are required to hold
> dev->struct_mutex, which these paths don't. Enforcing this requirement
> has become a bit more strict with
> 
> commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663
> Author: Daniel Vetter 
> Date:   Thu Oct 15 09:36:25 2015 +0200
> 
> drm/gem: Check locking in drm_gem_object_unreference
> 
> Cc: Dave Airlie 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/udl/udl_fb.c  | 2 +-
>  drivers/gpu/drm/udl/udl_gem.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index 33239a2b264a..fd1eb9d03f0b 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -536,7 +536,7 @@ static int udlfb_create(struct drm_fb_helper *helper,
>  out_destroy_fbi:
>   drm_fb_helper_release_fbi(helper);
>  out_gfree:
> - drm_gem_object_unreference(>ufb.obj->base);
> + drm_gem_object_unreference_unlocked(>ufb.obj->base);
>  out:
>   return ret;
>  }
> diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
> index 2a0a784ab6ee..d7528e0d8442 100644
> --- a/drivers/gpu/drm/udl/udl_gem.c
> +++ b/drivers/gpu/drm/udl/udl_gem.c
> @@ -52,7 +52,7 @@ udl_gem_create(struct drm_file *file,
>   return ret;
>   }
>  
> - drm_gem_object_unreference(>base);
> + drm_gem_object_unreference_unlocked(>base);
>   *handle_p = handle;
>   return 0;
>  }
> 

Reviewed-by: poma 

Two kangaroo

[poma]

First Kangaroo: What does a frog say when it washes car windows?
Second Kangaroo: Rub it, rub it, rub it.

https://lists.freedesktop.org/archives/dri-devel/2016-January/097945.html
https://patchwork.freedesktop.org/patch/65722
https://bugzilla.redhat.com/show_bug.cgi?id=1295646

It's been more than 100 sunsets,
Mister Crocodile Dundee, care to throw a boomerang, finally?

[PATCH 27/29] drm/vgem: Move get_pages to gem_create

[poma]

On 23.11.2015 10:33, Daniel Vetter wrote:
> vgem doesn't have a shrinker or anything like that and drops backing
> storage only at object_free time. There's no use in trying to be
> clever and allocating backing storage delayed, it only causes trouble
> by requiring locking.
> 
> Instead grab pages when we allocate the object right away.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/vgem/vgem_drv.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 63026d4324ad..1a609347236b 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -154,6 +154,10 @@ static struct drm_gem_object *vgem_gem_create(struct 
> drm_device *dev,
>   if (err)
>   goto out;
>  
> + ret = vgem_gem_get_pages(to_vgem_bo(obj));
> + if (ret)
> + goto out;
> +
>   err = drm_gem_handle_create(file, gem_object, handle);
>   if (err)
>   goto handle_out;
> @@ -216,16 +220,8 @@ int vgem_gem_dumb_map(struct drm_file *file, struct 
> drm_device *dev,
>  
>   obj->filp->private_data = obj;
>  
> - ret = vgem_gem_get_pages(to_vgem_bo(obj));
> - if (ret)
> - goto fail_get_pages;
> -
>   *offset = drm_vma_node_offset_addr(>vma_node);
>  
> - goto unref;
> -
> -fail_get_pages:
> - drm_gem_free_mmap_offset(obj);
>  unref:
>   drm_gem_object_unreference(obj);
>  unlock:
> 


drivers/gpu/drm/vgem/vgem_drv.c: In function 'vgem_gem_fault':
drivers/gpu/drm/vgem/vgem_drv.c:92:21: warning: unused variable 'dev' 
[-Wunused-variable]
  struct drm_device *dev = obj->base.dev;
 ^
drivers/gpu/drm/vgem/vgem_drv.c: In function 'vgem_gem_create':
drivers/gpu/drm/vgem/vgem_drv.c:153:2: error: 'ret' undeclared (first use in 
this function)
  ret = vgem_gem_get_pages(to_vgem_bo(obj));
  ^
drivers/gpu/drm/vgem/vgem_drv.c:153:2: note: each undeclared identifier is 
reported only once for each function it appears in
In file included from include/linux/list.h:8:0,
 from include/linux/module.h:9,
 from drivers/gpu/drm/vgem/vgem_drv.c:33:
include/linux/kernel.h:813:48: warning: initialization from incompatible 
pointer type [-Wincompatible-pointer-types]
  const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
drivers/gpu/drm/vgem/vgem_drv.h:35:23: note: in expansion of macro 
'container_of'
 #define to_vgem_bo(x) container_of(x, struct drm_vgem_gem_object, base)
   ^
drivers/gpu/drm/vgem/vgem_drv.c:153:27: note: in expansion of macro 'to_vgem_bo'
  ret = vgem_gem_get_pages(to_vgem_bo(obj));
   ^

This breaks the build, therefore "armada" batch cannot be tested entirely.

WARNING: CPU: 3 PID: 914 at include/drm/drm_gem.h:146 udl_dumb_create+0xdd/0xf0 [udl]()

[poma]

On 05.01.2016 09:49, Daniel Vetter wrote:
> On Tue, Jan 05, 2016 at 08:46:19AM +0100, poma wrote:
>>
>> Hi Fi
>>
>> Please take a loo kat
>> https://bugzilla.redhat.com/show_bug.cgi?id=1295646
> 
> Patches to fix these have been hanging around on the list for weeks,
> looking for review ... The entire series starts with "drm/armada: Use
> unlocked gem unreferencing". Care to review them all?
> 
> Thanks, Daniel
> 

https://patchwork.freedesktop.org/project/intel-gfx/patches/?page=9

"armada" batch for udl builds and works OK.

Tested-by: poma 

WARNING: CPU: 3 PID: 914 at include/drm/drm_gem.h:146 udl_dumb_create+0xdd/0xf0 [udl]()

[poma]

Hi Fi

Please take a loo kat
https://bugzilla.redhat.com/show_bug.cgi?id=1295646

[Nouveau] nouveau sync DMA memory not allocated

[poma]

On 12.11.2015 14:48, Thierry Reding wrote:
> On Wed, Nov 11, 2015 at 09:12:33PM +0100, poma wrote:
>> On 10.11.2015 17:25, Mario Kleiner wrote:
>>> On 11/10/2015 05:00 PM, Thierry Reding wrote:
>>>> On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote:
>>>>> From: Daniel Vetter 
>>>>>
>>>>> Apparently pre-nv50 pageflip events happen before the actual vblank
>>>>> period. Therefore that functionality got semi-disabled in
>>>>>
>>>>> commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28
>>>>> Author: Mario Kleiner 
>>>>> Date:   Tue May 13 00:42:08 2014 +0200
>>>>>
>>>>>  drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.
>>>>>
>>>>> Unfortunately that hack got uprooted in
>>>>>
>>>>> commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb
>>>>> Author: Thierry Reding 
>>>>> Date:   Wed Aug 12 17:00:31 2015 +0200
>>>>>
>>>>>  drm/irq: Make pipe unsigned and name consistent
>>>>>
>>>>> Trigering a warning when trying to sample the vblank timestamp for a
>>>>> non-existing pipe. There's a few ways to fix this:
>>>>>
>>>>> - Open-code the old behaviour, which just enshrines this slight
>>>>>breakage of the userspace ABI.
>>>>>
>>>>> - Revert Mario's commit and again inflict broken timestamps, again not
>>>>>pretty.
>>>>>
>>>>> - Fix this for real by delaying the pageflip TS until the next vblank
>>>>>interrupt, thereby making it accurate.
>>>>>
>>>>> This patch implements the third option. Since having a page flip
>>>>> interrupt that happens when the pageflip gets armed and not when it
>>>>> completes in the next vblank seems to be fairly common (older i915 hw
>>>>> works very similarly) create a new helper to arm vblank events for
>>>>> such drivers.
>>>>>
>>>>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431
>>>>> Cc: Thierry Reding 
>>>>> Cc: Mario Kleiner 
>>>>> Cc: Ben Skeggs 
>>>>> Cc: Ilia Mirkin 
>>>>>
>>>>> v2 (mario): Integrate my own review comments into Daniels patch.
>>>>> - Fix function prototypes in drmP.h
>>>>> - Add missing vblank_put() for pageflip completion without
>>>>>   pageflip event.
>>>>> - Initialize sequence number for queued pageflip event to avoidng
>>>>>   trouble in drm_handle_vblank_events().
>>>>> - Remove dead code and spelling fix.
>>>>>
>>>>> v3 (mario): Add a signed-off-by and cc stable tag per Ilja's advice.
>>>>>
>>>>> Signed-off-by: Daniel Vetter 
>>>>> (v1) Reviewed-by: Mario Kleiner 
>>>>> (v2/v3) Signed-off-by: Mario Kleiner 
>>>>>
>>>>> Cc: stable at vger.kernel.org # v4.3
>>>>> ---
>>>>>   drivers/gpu/drm/drm_irq.c | 54 
>>>>> ++-
>>>>>   drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++-
>>>>>   include/drm/drmP.h|  4 +++
>>>>>   3 files changed, 68 insertions(+), 9 deletions(-)
>>>>
>>>> This looks good to me. Let me clean this up a little and submit it to
>>>> Dave.
>>>>
>>>> Thierry
>>>>
>>>
>>> Btw., if somebody has a functional old card for testing this, it should 
>>> be easy to verify if it works on pre-nv50. If it would not work it would 
>>> deliver the pageflip event 1 frame delayed, so at least on standard 
>>> nouveau + default DRI2 + default double-buffering the rate for a tight 
>>> loop of page-flipped swaps should go down to 30 fps on a 60 Hz display, 
>>> quite noticeable. Afaik we also have Piglit tests for OML_sync_control 
>>> which would likely fail if this would be broken.
>>>
>>> Oh and if someone has tips on how to resurrect an old nv-40 PC (booted 
>>> with BIOS only) graphics card in a MacPro (EFI boot), i wouldn't mind 
>>> hearing them. It would be nice to still be able to use that card for 
>>> testing.
>>>
>>> thanks,
>>> -mario
>>
>>
>> [ cut here ]
>> WARNING

[Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v4)

[poma]

On 15.12.2015 12:21, Emil Velikov wrote:
> On 15 December 2015 at 11:11, poma  wrote:
> 
>>
>> Apparently not reached @stable (stable: 4.3.3 2015-12-15),
>> so here's one more time.
>>
> It has reached 4.4-rcX and will get picked by the stable maintainer
> (Greg?) in due time. Meanwhile you can ask your distro maintainers to
> apply it locally until we get an official release that includes it.
> 
> -Emil
> 

It is all but unknown ;)
https://bugzilla.redhat.com/show_bug.cgi?id=1281368

Emil, the point is - if it has -not- reached stable at vger.kernel.org, how can 
it be applied, in the first place.

Aye

[PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v4)

[poma]

On 10.11.2015 17:41, Thierry Reding wrote:
> On Tue, Nov 10, 2015 at 05:37:31PM +0100, Thierry Reding wrote:
>> From: Daniel Vetter 
>>
>> Apparently pre-nv50 pageflip events happen before the actual vblank
>> period. Therefore that functionality got semi-disabled in
>>
>> commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28
>> Author: Mario Kleiner 
>> Date:   Tue May 13 00:42:08 2014 +0200
>>
>> drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.
>>
>> Unfortunately that hack got uprooted in
>>
>> commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb
>> Author: Thierry Reding 
>> Date:   Wed Aug 12 17:00:31 2015 +0200
>>
>> drm/irq: Make pipe unsigned and name consistent
>>
>> Triggering a warning when trying to sample the vblank timestamp for a
>> non-existing pipe. There's a few ways to fix this:
>>
>> - Open-code the old behaviour, which just enshrines this slight
>>   breakage of the userspace ABI.
>>
>> - Revert Mario's commit and again inflict broken timestamps, again not
>>   pretty.
>>
>> - Fix this for real by delaying the pageflip TS until the next vblank
>>   interrupt, thereby making it accurate.
>>
>> This patch implements the third option. Since having a page flip
>> interrupt that happens when the pageflip gets armed and not when it
>> completes in the next vblank seems to be fairly common (older i915 hw
>> works very similarly) create a new helper to arm vblank events for
>> such drivers.
>>
>> v2 (Mario Kleiner):
>> - Fix function prototypes in drmP.h
>> - Add missing vblank_put() for pageflip completion without
>>   pageflip event.
>> - Initialize sequence number for queued pageflip event to avoid
>>   trouble in drm_handle_vblank_events().
>> - Remove dead code and spelling fix.
>>
>> v3 (Mario Kleiner):
>> - Add a signed-off-by and cc stable tag per Ilja's advice.
>>
>> v4 (Thierry Reding):
>> - Fix kerneldoc typo, discovered by Michel Dänzer
>> - Rearrange tags and changelog
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431
>> Cc: Thierry Reding 
>> Cc: Mario Kleiner 
>> Cc: Ben Skeggs 
>> Cc: Ilia Mirkin 
>> Signed-off-by: Daniel Vetter 
>> Reviewed-by: Mario Kleiner 
>> Cc: stable at vger.kernel.org # v4.3
>> Signed-off-by: Mario Kleiner 
>> Signed-off-by: Thierry Reding 
>> ---
>>  drivers/gpu/drm/drm_irq.c | 54 
>> ++-
>>  drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++-
>>  include/drm/drmP.h|  4 +++
>>  3 files changed, 68 insertions(+), 9 deletions(-)
> 
> Hi Dave,
> 
> It'd be great if you could queue this up for fixes, since it gets rid of
> a WARN_ON() that is triggered on a number of cards in v4.3. I realize
> that this is a tad big for stable, but it's the right way to fix this.
> If you'd prefer something smaller, I think we can fix the regression
> using a one-line band-aid and then apply this one on top for v4.4.
> 
> Thierry
> 


Apparently not reached @stable (stable: 4.3.3 2015-12-15),
so here's one more time.

[PATCH] drm/nouveau: Fix pre-nv50 pageflip events

[poma]

On 02.12.2015 09:55, Daniel Vetter wrote:
> On Wed, Dec 02, 2015 at 06:40:32AM +0100, poma wrote:
>> On Tue, Dec 1, 2015 at 6:30 PM, Mario Kleiner
>>  wrote:
>>> When we are at it, the one with the title "[PATCH] drm/nouveau: Use
>>> drm_vblank_on/off consistently" from Daniel, which has a reviewed and tested
>>> by me also never made it into nouveau.
>>>
>>> Maybe pick that up as well?
>>>
>>> -mario
>>>
>>
>> If you refer to
>> "[1/3] drm/nouveau: Use drm_vblank_on/off consistently"
>> https://patchwork.freedesktop.org/patch/50771
>>
>> this is the result:
>> patched 4.4.0-0.rc3.git0.1.fc24.x86_64 with it,
>> i.e. 1-3-drm-nouveau-Use-drm_vblank_on-off-consistently.patch
>>
>> # cat /var/log/Xorg.0.log
>> [   126.360]
>> X.Org X Server 1.18.0
>> ...
>> [   126.909] (EE) [drm] Failed to open DRM device for pci::02:00.0: -19
>> [   126.909] (EE) No devices detected.
>> [   126.909] (EE)
>> Fatal server error:
>> [   126.909] (EE) no screens found(EE)
>> [   126.909] (EE)
>> Please consult 
> 
> Kernel log needed if the drm device isn't there. And this is pretty much
> impossible, worst case modesetting is functionally busted.
> -Daniel
> 


Pardon me,
I missed 0 in EXTRAVERSION, therefore version magic not so pretty.

$ sed -i 's/-rc3/\-0.rc3/' Makefile

[ 1771.699138] checking generic (f700 e0) vs hw (d000 1000)
[ 1771.699143] checking generic (f700 e0) vs hw (f600 200)
[ 1771.699144] fb: switching to nouveaufb from VESA VGA
[ 1771.699271] Console: switching to colour dummy device 80x25
[ 1771.699450] nouveau :02:00.0: NVIDIA G98 (098200a2)
[ 1771.813968] nouveau :02:00.0: bios: version 62.98.2c.00.00
[ 1771.834802] nouveau :02:00.0: bios: M0203T not found
[ 1771.834819] nouveau :02:00.0: bios: M0203E not matched!
[ 1771.834830] nouveau :02:00.0: fb: 512 MiB DDR2
[ 1774.593921] [TTM] Zone  kernel: Available graphics memory: 1891762 kiB
[ 1774.593926] [TTM] Initializing pool allocator
[ 1774.593932] [TTM] Initializing DMA pool allocator
[ 1774.593948] nouveau :02:00.0: DRM: VRAM: 512 MiB
[ 1774.593950] nouveau :02:00.0: DRM: GART: 1048576 MiB
[ 1774.593954] nouveau :02:00.0: DRM: TMDS table version 2.0
[ 1774.593956] nouveau :02:00.0: DRM: DCB version 4.0
[ 1774.593959] nouveau :02:00.0: DRM: DCB outp 00: 02000300 0028
[ 1774.593962] nouveau :02:00.0: DRM: DCB outp 01: 01000302 00020030
[ 1774.593964] nouveau :02:00.0: DRM: DCB outp 02: 04011310 0028
[ 1774.593966] nouveau :02:00.0: DRM: DCB outp 03: 010223f1 00c0c080
[ 1774.593969] nouveau :02:00.0: DRM: DCB conn 00: 1030
[ 1774.593971] nouveau :02:00.0: DRM: DCB conn 01: 0100
[ 1774.593973] nouveau :02:00.0: DRM: DCB conn 02: 0210
[ 1774.593975] nouveau :02:00.0: DRM: DCB conn 03: 0211
[ 1774.593977] nouveau :02:00.0: DRM: DCB conn 04: 0213
[ 1774.595827] nouveau :02:00.0: DRM: failed to create encoder 0/1/0: -19
[ 1774.595832] nouveau :02:00.0: DRM: TV-1 has no encoders, removing
[ 1774.595867] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 1774.595870] [drm] Driver supports precise vblank timestamp query.
[ 1774.600023] CE: hpet increased min_delta_ns to 11521 nsec
[ 1774.605699] nouveau :02:00.0: DRM: MM: using M2MF for buffer copies
[ 1774.690808] nouveau :02:00.0: DRM: allocated 1024x768 fb: 0x5, bo 
8800c9a46000
[ 1774.690960] fbcon: nouveaufb (fb0) is primary device
[ 1774.746581] Console: switching to colour frame buffer device 128x48
[ 1774.747411] nouveau :02:00.0: fb0: nouveaufb frame buffer device
[ 1774.750093] [drm] Initialized nouveau 1.3.1 20120801 for :02:00.0 on 
minor 0


Tested-by: poma 

[PATCH] drm/nouveau: Fix pre-nv50 pageflip events

[poma]

On Tue, Dec 1, 2015 at 6:30 PM, Mario Kleiner
 wrote:
> When we are at it, the one with the title "[PATCH] drm/nouveau: Use
> drm_vblank_on/off consistently" from Daniel, which has a reviewed and tested
> by me also never made it into nouveau.
>
> Maybe pick that up as well?
>
> -mario
>

If you refer to
"[1/3] drm/nouveau: Use drm_vblank_on/off consistently"
https://patchwork.freedesktop.org/patch/50771

this is the result:
patched 4.4.0-0.rc3.git0.1.fc24.x86_64 with it,
i.e. 1-3-drm-nouveau-Use-drm_vblank_on-off-consistently.patch

# cat /var/log/Xorg.0.log
[   126.360]
X.Org X Server 1.18.0
...
[   126.909] (EE) [drm] Failed to open DRM device for pci::02:00.0: -19
[   126.909] (EE) No devices detected.
[   126.909] (EE)
Fatal server error:
[   126.909] (EE) no screens found(EE)
[   126.909] (EE)
Please consult 
...

[PATCH] drm/nouveau: Fix pre-nv50 pageflip events

[poma]

On Mon, Nov 16, 2015 at 4:11 PM, Daniel Vetter  wrote:
> On Mon, Nov 02, 2015 at 04:45:00PM +0900, Michel Dänzer wrote:
>> On 31.10.2015 06:55, Daniel Vetter wrote:
>> > Apparently pre-nv50 pageflip events happen before the actual vblank
>> > period. Therefore that functionality got semi-disabled in
>> >
>> > commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28
>> > Author: Mario Kleiner 
>> > Date:   Tue May 13 00:42:08 2014 +0200
>> >
>> > drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.
>> >
>> > Unfortunately that hack got uprooted in
>> >
>> > commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb
>> > Author: Thierry Reding 
>> > Date:   Wed Aug 12 17:00:31 2015 +0200
>> >
>> > drm/irq: Make pipe unsigned and name consistent
>> >
>> > Trigering a warning when trying to sample the vblank timestamp for a
>> > non-existing pipe. There's a few ways to fix this:
>> >
>> > - Open-code the old behaviour, which just enshrines this slight
>> >   breakage of the userspace ABI.
>> >
>> > - Revert Mario's commit and again inflict broken timestamps, again not
>> >   pretty.
>> >
>> > - Fix this for real by delaying the pageflip TS until the next vblank
>> >   interrupt, thereby making it accurate.
>> >
>> > This patch implements the third option. Since having a page flip
>> > interrupt that happens when the pageflip gets armed and not when it
>> > completes in the next vblank seems to be fairly common (older i915 hw
>> > works very similarly) create a new helper to arm vblank events for
>> > such drivers.
>>
>> What happens when the page flip interrupt arrives during a vertical
>> blank period?  Presumably the userspace event will be deferred until the
>> next vertical blank period, but the flip might already take effect in
>> the current one.
>
> Hm yeah there's a tiny race if your update handler for the pageflip can
> race with your vblank handler. That's impossible here since it's all done
> from the same hw irq hanlder, and since that is single-threaded there
> shouldn't be a problem, as long as vblank handling are pageflip are
> ordered correctly.
>
> Might be worth a note in the kerneldoc though that this function isn't
> perfectly foolproof.
> -Daniel


Is there any updates in this respect?

drm-nouveau-Fix-pre-nv50-pageflip-events-v4.patch
https://patchwork.kernel.org/patch/7591531

https://bugzilla.kernel.org/show_bug.cgi?id=106431
Reported: 2015-10-21

[Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v3) -> v4

[poma]

On 12.11.2015 14:48, Thierry Reding wrote:
> On Wed, Nov 11, 2015 at 09:12:33PM +0100, poma wrote:
>> On 10.11.2015 17:25, Mario Kleiner wrote:
>>> On 11/10/2015 05:00 PM, Thierry Reding wrote:
>>>> On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote:
>>>>> From: Daniel Vetter 
>>>>>
>>>>> Apparently pre-nv50 pageflip events happen before the actual vblank
>>>>> period. Therefore that functionality got semi-disabled in
>>>>>
>>>>> commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28
>>>>> Author: Mario Kleiner 
>>>>> Date:   Tue May 13 00:42:08 2014 +0200
>>>>>
>>>>>  drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.
>>>>>
>>>>> Unfortunately that hack got uprooted in
>>>>>
>>>>> commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb
>>>>> Author: Thierry Reding 
>>>>> Date:   Wed Aug 12 17:00:31 2015 +0200
>>>>>
>>>>>  drm/irq: Make pipe unsigned and name consistent
>>>>>
>>>>> Trigering a warning when trying to sample the vblank timestamp for a
>>>>> non-existing pipe. There's a few ways to fix this:
>>>>>
>>>>> - Open-code the old behaviour, which just enshrines this slight
>>>>>breakage of the userspace ABI.
>>>>>
>>>>> - Revert Mario's commit and again inflict broken timestamps, again not
>>>>>pretty.
>>>>>
>>>>> - Fix this for real by delaying the pageflip TS until the next vblank
>>>>>interrupt, thereby making it accurate.
>>>>>
>>>>> This patch implements the third option. Since having a page flip
>>>>> interrupt that happens when the pageflip gets armed and not when it
>>>>> completes in the next vblank seems to be fairly common (older i915 hw
>>>>> works very similarly) create a new helper to arm vblank events for
>>>>> such drivers.
>>>>>
>>>>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431
>>>>> Cc: Thierry Reding 
>>>>> Cc: Mario Kleiner 
>>>>> Cc: Ben Skeggs 
>>>>> Cc: Ilia Mirkin 
>>>>>
>>>>> v2 (mario): Integrate my own review comments into Daniels patch.
>>>>> - Fix function prototypes in drmP.h
>>>>> - Add missing vblank_put() for pageflip completion without
>>>>>   pageflip event.
>>>>> - Initialize sequence number for queued pageflip event to avoidng
>>>>>   trouble in drm_handle_vblank_events().
>>>>> - Remove dead code and spelling fix.
>>>>>
>>>>> v3 (mario): Add a signed-off-by and cc stable tag per Ilja's advice.
>>>>>
>>>>> Signed-off-by: Daniel Vetter 
>>>>> (v1) Reviewed-by: Mario Kleiner 
>>>>> (v2/v3) Signed-off-by: Mario Kleiner 
>>>>>
>>>>> Cc: stable at vger.kernel.org # v4.3
>>>>> ---
>>>>>   drivers/gpu/drm/drm_irq.c | 54 
>>>>> ++-
>>>>>   drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++-
>>>>>   include/drm/drmP.h|  4 +++
>>>>>   3 files changed, 68 insertions(+), 9 deletions(-)
>>>>
>>>> This looks good to me. Let me clean this up a little and submit it to
>>>> Dave.
>>>>
>>>> Thierry
>>>>
>>>
>>> Btw., if somebody has a functional old card for testing this, it should 
>>> be easy to verify if it works on pre-nv50. If it would not work it would 
>>> deliver the pageflip event 1 frame delayed, so at least on standard 
>>> nouveau + default DRI2 + default double-buffering the rate for a tight 
>>> loop of page-flipped swaps should go down to 30 fps on a 60 Hz display, 
>>> quite noticeable. Afaik we also have Piglit tests for OML_sync_control 
>>> which would likely fail if this would be broken.
>>>
>>> Oh and if someone has tips on how to resurrect an old nv-40 PC (booted 
>>> with BIOS only) graphics card in a MacPro (EFI boot), i wouldn't mind 
>>> hearing them. It would be nice to still be able to use that card for 
>>> testing.
>>>
>>> thanks,
>>> -mario
>>
>>
>> [ cut here ]
>> WARNING

[Nouveau] [PATCH] drm/nouveau: Fix pre-nv50 pageflip events (v3) -> v4

[poma]

On 10.11.2015 17:25, Mario Kleiner wrote:
> On 11/10/2015 05:00 PM, Thierry Reding wrote:
>> On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote:
>>> From: Daniel Vetter 
>>>
>>> Apparently pre-nv50 pageflip events happen before the actual vblank
>>> period. Therefore that functionality got semi-disabled in
>>>
>>> commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28
>>> Author: Mario Kleiner 
>>> Date:   Tue May 13 00:42:08 2014 +0200
>>>
>>>  drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.
>>>
>>> Unfortunately that hack got uprooted in
>>>
>>> commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb
>>> Author: Thierry Reding 
>>> Date:   Wed Aug 12 17:00:31 2015 +0200
>>>
>>>  drm/irq: Make pipe unsigned and name consistent
>>>
>>> Trigering a warning when trying to sample the vblank timestamp for a
>>> non-existing pipe. There's a few ways to fix this:
>>>
>>> - Open-code the old behaviour, which just enshrines this slight
>>>breakage of the userspace ABI.
>>>
>>> - Revert Mario's commit and again inflict broken timestamps, again not
>>>pretty.
>>>
>>> - Fix this for real by delaying the pageflip TS until the next vblank
>>>interrupt, thereby making it accurate.
>>>
>>> This patch implements the third option. Since having a page flip
>>> interrupt that happens when the pageflip gets armed and not when it
>>> completes in the next vblank seems to be fairly common (older i915 hw
>>> works very similarly) create a new helper to arm vblank events for
>>> such drivers.
>>>
>>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431
>>> Cc: Thierry Reding 
>>> Cc: Mario Kleiner 
>>> Cc: Ben Skeggs 
>>> Cc: Ilia Mirkin 
>>>
>>> v2 (mario): Integrate my own review comments into Daniels patch.
>>> - Fix function prototypes in drmP.h
>>> - Add missing vblank_put() for pageflip completion without
>>>   pageflip event.
>>> - Initialize sequence number for queued pageflip event to avoidng
>>>   trouble in drm_handle_vblank_events().
>>> - Remove dead code and spelling fix.
>>>
>>> v3 (mario): Add a signed-off-by and cc stable tag per Ilja's advice.
>>>
>>> Signed-off-by: Daniel Vetter 
>>> (v1) Reviewed-by: Mario Kleiner 
>>> (v2/v3) Signed-off-by: Mario Kleiner 
>>>
>>> Cc: stable at vger.kernel.org # v4.3
>>> ---
>>>   drivers/gpu/drm/drm_irq.c | 54 
>>> ++-
>>>   drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++-
>>>   include/drm/drmP.h|  4 +++
>>>   3 files changed, 68 insertions(+), 9 deletions(-)
>>
>> This looks good to me. Let me clean this up a little and submit it to
>> Dave.
>>
>> Thierry
>>
> 
> Btw., if somebody has a functional old card for testing this, it should 
> be easy to verify if it works on pre-nv50. If it would not work it would 
> deliver the pageflip event 1 frame delayed, so at least on standard 
> nouveau + default DRI2 + default double-buffering the rate for a tight 
> loop of page-flipped swaps should go down to 30 fps on a 60 Hz display, 
> quite noticeable. Afaik we also have Piglit tests for OML_sync_control 
> which would likely fail if this would be broken.
> 
> Oh and if someone has tips on how to resurrect an old nv-40 PC (booted 
> with BIOS only) graphics card in a MacPro (EFI boot), i wouldn't mind 
> hearing them. It would be nice to still be able to use that card for 
> testing.
> 
> thanks,
> -mario


[ cut here ]
WARNING: CPU: 0 PID: 313 at lib/dma-debug.c:1205 check_sync+0x169/0x6e0()
nouveau :01:00.0: DMA-API: device driver tries to sync DMA memory it has 
not allocated [device address=0xc0bf6468] [size=4096 bytes]
Modules linked in: nouveau(+) ...
CPU: 0 PID: 313 Comm: systemd-udevd Not tainted 4.3.0-3.fc22.i686+debug #1
...
Call Trace:
 [] dump_stack+0x48/0x69
 [] warn_slowpath_common+0x87/0xc0
 [] ? check_sync+0x169/0x6e0
 [] ? check_sync+0x169/0x6e0
 [] warn_slowpath_fmt+0x3e/0x60
 [] check_sync+0x169/0x6e0
 [] debug_dma_sync_single_for_device+0x7d/0x90
 [] ? ttm_bo_del_sub_from_lru+0x18/0x50 [ttm]
 [] ? text_poke_bp+0xd0/0xd0
 [] nouveau_bo_sync_for_device+0x8b/0xa0 [nouveau]
 [] nouveau_bo_validate+0x34/0x40 [nouveau]
 [] nouveau_bo_pin+0x188/0x290 [nouveau]
 [] ? nv10_bo_put_tile_region+0x80/0x80 [nouveau]
 [] nouveau_channel_prep+0xfd/0x2c0 [nouveau]
 [] nouveau_channel_new+0x57/0x7a0 [nouveau]
 [] ? kfree+0xdc/0x280
 [] ? nvif_object_sclass_put+0x12/0x20 [nouveau]
 [] nouveau_drm_load+0x596/0x8d0 [nouveau]
 [] ? trace_hardirqs_on_caller+0x12c/0x1d0
 [] ? drm_minor_register+0x89/0x120 [drm]
 [] drm_dev_register+0x96/0xa0 [drm]
 [] drm_get_pci_dev+0x79/0x1c0 [drm]
 [] ? pcibios_set_master+0x4e/0xa0
 [] nouveau_drm_probe+0x1ee/0x220 [nouveau]
 [] pci_device_probe+0x7b/0xf0
 [] ? devices_kset_move_last+0x56/0xa0
 [] driver_probe_device+0x204/0x490
 [] ? __driver_attach+0x4c/0x90
 [] ? pci_match_device+0xd2/0x100
 [] __driver_attach+0x81/0x90
 [] ? driver_probe_device+0x490/0x490
 [] 

[PATCH v2 2/2] drm/qxl: avoid dependency lock

[poma]

On 24.09.2015 15:25, Frediano Ziglio wrote:
> qxl_bo_unref calls drm_gem_object_unreference_unlocked which
> locks dev->struct_mutex. However this lock could be already
> locked if the call came from qxl_gem_object_free.
> As we don't need to call qxl_bo_ref/qxl_bo_unref cause
> qxl_release_list_add will hold a reference by itself avoid
> to call them and the possible deadlock.
> 
> Signed-off-by: Frediano Ziglio 
> ---
>  drivers/gpu/drm/qxl/qxl_release.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
> b/drivers/gpu/drm/qxl/qxl_release.c
> index b66ec33..4efa8e2 100644
> --- a/drivers/gpu/drm/qxl/qxl_release.c
> +++ b/drivers/gpu/drm/qxl/qxl_release.c
> @@ -307,7 +307,7 @@ int qxl_alloc_surface_release_reserved(struct qxl_device 
> *qdev,
>   idr_ret = qxl_release_alloc(qdev, QXL_RELEASE_SURFACE_CMD, 
> release);
>   if (idr_ret < 0)
>   return idr_ret;
> - bo = qxl_bo_ref(to_qxl_bo(entry->tv.bo));
> + bo = to_qxl_bo(entry->tv.bo);
>  
>   (*release)->release_offset = create_rel->release_offset + 64;
>  
> @@ -316,8 +316,6 @@ int qxl_alloc_surface_release_reserved(struct qxl_device 
> *qdev,
>   info = qxl_release_map(qdev, *release);
>   info->id = idr_ret;
>   qxl_release_unmap(qdev, *release, info);
> -
> - qxl_bo_unref();
>   return 0;
>   }
>  
> 


Tested with:
 - Rawhide-Xfce-Live-1001.iso
  \ 4.3.0-0.rc3.git2.4.fc24.x86_64
   + v2-1-2-drm-qxl-avoid-buffer-reservation-in-qxl_crtc_page_flip.patch
   + v2-2-2-drm-qxl-avoid-dependency-lock.patch

Tested-by: poma 

Virtio GPU - hotplug_mode_update_property

[poma]

Does virtgpu provides the same or a similar mechanism as QXL virtual GPU does?
Dynamic guest resizing related.


Ref.
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/qxl/qxl_display.c?id=4695b03

drm_kms_helper.edid_firmware=DVI-I-1 - resume(S3) - DVI-I-2: EDID broken

[poma]

[0.00] Linux version 3.18.0-0.rc0.git2.1.fc22.x86_64 (mockbuild at 
bkernel01.phx2.fedoraproject.org) (gcc version 4.9.1 20140930 (Red Hat 
4.9.1-11) (GCC) ) #1 SMP Thu Oct 9 13:57:38 UTC 2014
[0.00] Command line: 
BOOT_IMAGE=/vmlinuz-3.18.0-0.rc0.git2.1.fc22.x86_64 
root=UUID=a07556d2-6fe2-417f-8202-c54c07fd9386 
drm_kms_helper.edid_firmware=DVI-I-1:edid/848x480.bin 
initrd=/initramfs-3.18.0-0.rc0.git2.1.fc22.x86_64.img
[4.396325] usb 1-6: new high-speed USB device number 7 using ehci-pci
[4.520203] usb 1-6: New USB device found, idVendor=17e9, idProduct=019e
[4.520357] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[4.520499] usb 1-6: Product: FY USB-DVI
[4.520629] usb 1-6: Manufacturer: DisplayLink
[4.520761] usb 1-6: SerialNumber: USB_FY1704
[   23.261365] [drm] Initialized drm 1.1.0 20060810
[   24.415915] [drm] vendor descriptor length:1b data:1b 5f 01 00 19 05 00 01 
03 00 04
[   24.734381] [drm] Got external EDID base block and 0 extensions from 
"edid/848x480.bin" for connector "DVI-I-1"
[   24.749973] open /dev/fb0 user=0 fb_info=8800c68ae000 count=1
[   24.762202] [drm] write mode info 153
[   24.785148] Console: switching to colour frame buffer device 106x30
[   24.799662] udl 1-6:1.0: fb0: udldrmfb frame buffer device
[   24.799731] udl 1-6:1.0: registered panic notifier
[   24.808392] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   24.810304] [drm] No driver support for vblank timestamp query.
[   24.812697] [drm] Initialized udl 0.0.1 20120220 on minor 0
[   24.815622] usbcore: registered new interface driver udl
[   35.269700] [drm] Got external EDID base block and 0 extensions from 
"edid/848x480.bin" for connector "DVI-I-1"
[   35.275096] [drm] Got external EDID base block and 0 extensions from 
"edid/848x480.bin" for connector "DVI-I-1"
[   35.344093] [drm] write mode info 153
[   36.950930] [drm] Got external EDID base block and 0 extensions from 
"edid/848x480.bin" for connector "DVI-I-1"

[  325.799612] PM: Preparing system for mem sleep
[  326.067140] PM: Entering mem sleep
[  326.068158] Suspending console(s) (use no_console_suspend to debug)
[  329.397361] PM: suspend of devices complete after 3323.665 msecs
[  329.397371] PM: suspend devices took 3.329 seconds
[  329.409465] PM: late suspend of devices complete after 12.074 msecs
[  329.420591] ehci-pci :00:04.1: System wakeup enabled by ACPI
[  329.431399] PM: noirq suspend of devices complete after 21.916 msecs
[  329.431455] ACPI: Preparing to enter system sleep state S3
[  329.840517] PM: Saving platform NVS memory

[  329.905021] ACPI: Low-level resume complete
[  329.905021] PM: Restoring platform NVS memory
[  329.976500] ACPI: Waking up from system sleep state S3
[  329.44] ehci-pci :00:04.1: System wakeup disabled by ACPI
[  330.003489] PM: noirq resume of devices complete after 19.016 msecs
[  330.012769] PM: early resume of devices complete after 9.022 msecs
[  332.101657] PM: resume of devices complete after 2088.867 msecs
[  332.113620] [drm] vendor descriptor length:1b data:1b 5f 01 00 19 05 00 01 
03 00 04
[  332.246592] Raw EDID:
[  332.246599]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.246603]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.246606]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.246609]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.246612]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.246615]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.246619]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.246622]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.246632] udl 1-6:1.0: DVI-I-2: EDID invalid.
[  332.262425] udl 1-6:1.0: fb2: udldrmfb frame buffer device
[  332.262492] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[  332.262495] [drm] No driver support for vblank timestamp query.
[  332.262507] [drm] Initialized udl 0.0.1 20120220 on minor 2
[  332.274311] PM: resume devices took 2.262 seconds
[  332.320387] PM: Finishing wakeup.
[  332.661252] Raw EDID:
[  332.661267]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.661277]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.661287]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.661296]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.661306]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.661317]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.661326]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.661336]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.661350] udl 1-6:1.0: DVI-I-2: EDID invalid.
[  332.791128] Raw EDID:
[  332.791148]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.791159]  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  332.791169]  

[systemd-devel] Someone working on gui for multiseat?

[poma]

On 02/11/13 21:30, Lennart Poettering wrote:
[?]
> Of course, doing this via the command line is not user-frienldy, but
> maybe this will one day get fixed and somebody writes a proper UI for
> it...
> 

Regarding 'loginctl attach seat0 ', the only thing really missing
is the 'sys' path completion, so one doesn't pars it via e.g. dmesg -t |
grep -P '(?=.*devices)(?=.*USB)', grep -B1 sys /var/log/Xorg.0.log, tree
/sys/class/drm, etc.
Behind the wheel, dri/drm device 'sys' path doesn't show up in dmesg,
nor in Xorg.*.log. - cc'ing dri-devel.

Cheers,
poma

Re: [systemd-devel] Someone working on gui for multiseat?

[poma]

On 02/11/13 21:30, Lennart Poettering wrote:
[…]
 Of course, doing this via the command line is not user-frienldy, but
 maybe this will one day get fixed and somebody writes a proper UI for
 it...
 

Regarding 'loginctl attach seat0 sysfs', the only thing really missing
is the 'sys' path completion, so one doesn't pars it via e.g. dmesg -t |
grep -P '(?=.*devices)(?=.*USB)', grep -B1 sys /var/log/Xorg.0.log, tree
/sys/class/drm, etc.
Behind the wheel, dri/drm device 'sys' path doesn't show up in dmesg,
nor in Xorg.*.log. - cc'ing dri-devel.

Cheers,
poma

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel