11/03/2011 05:03 AM, Jesse Barnes 쓴 글:
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse B
Hi.
I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl:
Some hardware (vmware's virtual in particular) may not be able to pick
up the changes from a bo directly, since the cursor data is sent though
the command stream. Hence we need a notification when the cursor image
h
From: Alex Deucher
It's already called via the DPMS functions.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c |6 --
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |6 --
2 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/r
From: Alex Deucher
The new power tables need to be handled differently when setting
up the profiles.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 51 +
drivers/gpu/drm/radeon/r600.c| 58 --
driver
From: Alex Deucher
Avoid a lot of extra loops through the pm state array.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c | 100 +
1 files changed, 32 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu
From: Alex Deucher
On newer chips the number of clock modes per power state varies.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_atombios.c | 118 -
2 files changed, 82 insertions(+), 39 deletions
On Fri, 04 Nov 2011 11:22:10 +0900
Joonyoung Shim wrote:
> > +struct drm_plane {
> > + struct drm_device *dev;
> > + struct device kdev;
> > + struct device_attribute *attr;
> > + struct list_head head;
> > +
> > + struct drm_mode_object base;
> > +
> > + uint32_t possible_crtcs;
> > +
On Fri, 04 Nov 2011 16:34:22 +0900
Joonyoung Shim wrote:
> > + case V4L2_PIX_FMT_RGB24:
> > + *depth = 24;
> > + *bpp = 24;
> > + break;
>
> In the depth = 24 and bpp = 32 case also the pixed_format is
> V4L2_PIX_FMT_RGB24, but above function cannot detect it.
On Fri, 4 Nov 2011, Thomas Hellstrom wrote:
Hi.
I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl:
Some hardware (vmware's virtual in particular) may not be able to pick up the
changes from a bo directly, since the cursor data is sent though the command
stream. Hence
On 11/04/2011 03:36 PM, Ilija Hadzic wrote:
On Fri, 4 Nov 2011, Thomas Hellstrom wrote:
Hi.
I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR
iotcl:
Some hardware (vmware's virtual in particular) may not be able to
pick up the changes from a bo directly, since the cursor
On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote:
> Hi.
>
> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl:
>
> Some hardware (vmware's virtual in particular) may not be able to
> pick up the changes from a bo directly, since the cursor data is
> sent tho
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #6 from DoTheDog 2011-11-04 08:37:52 PDT
---
Same issue here on the same hardward Sony Vaio VPCZ21 Power Media Dock. The USB
and disk drive work. Just not the ATI video.
DoTheDog
--
Configure bugmail: https://bugs.freedesktop.org/
(cc'ing David Airlie and dri-devel)
Hello, the original thread can be read from
http://thread.gmane.org/gmane.linux.kernel/1209587
Full sysrq-t output at
http://article.gmane.org/gmane.linux.kernel/1211256
So, the problem is that after a seemingly unreated update to input
serio driver (con
https://bugs.freedesktop.org/show_bug.cgi?id=40034
--- Comment #6 from Lauri Kasanen 2011-11-04 09:27:15
PDT ---
This bug doesn't seem to affect r700 - at least my HD4350 works perfectly with
all effects on current master (7.12-devel (git-f800a29))
--
Configure bugmail: https://bugs.freedeskto
Hi all,
I tried to create/pin ring BO in VRAM instead of GTT to debug some
ring-related problems. After I did this, it rendered a black screen in
X (on a X86 RS780E board), but radeon.test passed.
'ps aux' shows X uninterruptibly sleeps on radeon.
Curious why this does not work?
Regards,
-- Ch
This patch is preparing multiple display controllers, FIMD and HDMI.
- added padding into ioctl structure to be 64 bit align
- added kms poll to handle hpd event
- fixed converting between display mode and timing
- fixed connector and crtc callbacks to call proper display driver
- code clean
based
missing members are added into converting function between timing and display
mode and refresh rate of display mode is calculated by drm mode function.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c |9 -
1 files changed,
From: Inki Dae
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
include/drm/exynos_drm.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/drm/exynos_drm.h b/include/drm/exynos_drm.h
index 874c4d2..1d161cb 100644
--- a/include/drm/exynos_drm.h
+++ b/incl
From: Joonyoung Shim
during recreating exynos_drm_fbdev as a new display device probes,
fb_helper is reinitialized but kernel fb is not changed
so kernel_fb_list should be restored after fb_helper is reinitialized.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm
hdmi display in exynos supports hotplug event and interlace scan mode
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector
crtc dpms is called as destroying attached fb so dpms off sould be processed.
crtc dpms also can be called after crtc is detached from encoder so pipe value
of manager is used to find display controller for this case
Signed-off-by: Seung-Woo Kim
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Pa
From: Inki Dae
connector contains some contents for display controller so the connector also
should be able to access contoroller through manager.
Signed-off-by: Inki Dae
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 38 ++
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_encoder.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 4092f41..2d7a03
From: Inki Dae
exynos_drm_display has function pointes so exynos_drm_display_ops is better
to describe.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 29 +
drivers/gpu/drm/exynos/exynos_drm_drv.h |4
drm_framebuffer already has width and height so they are meaningless as
parameters when updating fb_info.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a
this patch adds kms poll infrastructure to handle hotplug detection event
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |5 +
drivers/gpu/drm/exynos/exynos_drm_fb.c | 12
2 files changed, 17 insertions(+), 0 deletio
Hi,
I'm facing a bug on a Samsung X20 notebook which features an i915
chipset (output of 'lspci -v' attached).
The effect is that setting the backlight to odd values causes the value
to be misinterpreted. Harald Hoyer (cc:) had the same thing on a Netbook
(I don't recall which model it was).
On Fri, Nov 04, 2011 at 09:14:31AM -0700, Tejun Heo wrote:
> (cc'ing David Airlie and dri-devel)
>
> Hello, the original thread can be read from
>
> http://thread.gmane.org/gmane.linux.kernel/1209587
>
> Full sysrq-t output at
>
> http://article.gmane.org/gmane.linux.kernel/1211256
>
> So,
On Fri, Nov 4, 2011 at 10:26 AM, Chen Jie wrote:
> Hi all,
>
> I tried to create/pin ring BO in VRAM instead of GTT to debug some
> ring-related problems. After I did this, it rendered a black screen in
> X (on a X86 RS780E board), but radeon.test passed.
> 'ps aux' shows X uninterruptibly sleeps
On Fri, Nov 4, 2011 at 1:34 PM, Andrew Watts wrote:
> On Fri, Nov 04, 2011 at 09:14:31AM -0700, Tejun Heo wrote:
>> Andrew, can you please kill the X server after the hang and see
>> whether that brings the system back? I think sshd should still work
>> and if not you can write a script to kill t
On Fri, Nov 04, 2011 at 12:34:58PM -0500, Andrew Watts wrote:
> On Fri, Nov 04, 2011 at 09:14:31AM -0700, Tejun Heo wrote:
> > Andrew, can you please kill the X server after the hang and see
> > whether that brings the system back? I think sshd should still work
> > and if not you can write a scri
On Fri, Nov 04, 2011 at 09:14:31AM -0700, Tejun Heo wrote:
> Andrew, can you please kill the X server after the hang and see
> whether that brings the system back? I think sshd should still work
> and if not you can write a script to kill the X server after 30secs
> after resume (and kill that scr
On Fri, Nov 04, 2011 at 01:44:01PM -0400, Jerome Glisse wrote:
>
> Attached patch might hide the issue.
>
> Cheers,
> Jerome
Unfortunately, the patch did not help.
Attached is the full hibernate->resume dmesg requested.
Thanks.
~ Andy
bad-dmesg.txt.gz
Description: application/gunzip
__
On 11/04/2011 04:34 PM, Daniel Vetter wrote:
On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote:
Hi.
I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl:
Some hardware (vmware's virtual in particular) may not be able to
pick up the changes from a bo direc
On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom wrote:
> On 11/04/2011 04:34 PM, Daniel Vetter wrote:
>>
>> On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote:
>>
>>>
>>> Hi.
>>>
>>> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl:
>>>
>>> Some hardware (vm
On 11/04/2011 11:49 PM, Maarten Maathuis wrote:
On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom wrote:
On 11/04/2011 04:34 PM, Daniel Vetter wrote:
On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote:
Hi.
I have a question about the semantics of the DRM_IOCT
On Fri, Nov 04, 2011 at 01:35:53PM -0400, Jerome Glisse wrote:
>
> I need full dmesg
>
> Cheers,
> Jerome
Hi. Just noticed I attached a gzip of my dmesg last time by mistake.
Here goes as text/plain.
~ Andy
[ 237.030115] PM: Marking nosave pages: 0009f000 - 0010
[ 237.03
On Fri, Nov 4, 2011 at 11:59 PM, Thomas Hellstrom wrote:
> On 11/04/2011 11:49 PM, Maarten Maathuis wrote:
>>
>> On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom
>> wrote:
>>
>>>
>>> On 11/04/2011 04:34 PM, Daniel Vetter wrote:
>>>
On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hells
https://bugs.freedesktop.org/show_bug.cgi?id=42490
--- Comment #9 from Mandeep Singh Baines
2011-11-03 19:15:58 PDT ---
Tested with drm-fixes-staging. Same behavior.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
11/03/2011 05:03 AM, Jesse Barnes ? ?:
> Planes are a bit like half-CRTCs. They have a location and fb, but
> don't drive outputs directly. Add support for handling them to the core
> KMS code.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/drm_crtc.c | 236
>
Hi Jesse,
It sees that there might be an overflow when crtc_w or crtc_h =0.
Following is my patch.
Thanks and best regards.
Hai Lan
When the crtc_w = 0 or crtc_h = 0, it should not be divided.
Besides, when (crtc_x+
---
drivers/gpu/drm/i915/intel_sprite.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 0891bd
11/03/2011 05:03 AM, Jesse Barnes ? ?:
> To properly support the various plane formats supported by different
> hardware, the kernel must know the pixel format of a framebuffer object.
> So add a new ioctl taking a format argument corresponding to a fourcc
> name from videodev2.h.
>
> Signed-off-by
Hi.
I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl:
Some hardware (vmware's virtual in particular) may not be able to pick
up the changes from a bo directly, since the cursor data is sent though
the command stream. Hence we need a notification when the cursor image
ha
From: Alex Deucher
It's already called via the DPMS functions.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c |6 --
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |6 --
2 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/r
From: Alex Deucher
The new power tables need to be handled differently when setting
up the profiles.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c | 51 +
drivers/gpu/drm/radeon/r600.c| 58 --
driver
From: Alex Deucher
Avoid a lot of extra loops through the pm state array.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600.c | 100 +
1 files changed, 32 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu
From: Alex Deucher
On newer chips the number of clock modes per power state varies.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_atombios.c | 118 -
2 files changed, 82 insertions(+), 39 deletions
.
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2004/dfe6df84/attachment.pgp>
Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2004/5b43a005/attachment.pgp>
On Fri, 4 Nov 2011, Thomas Hellstrom wrote:
> Hi.
>
> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl:
>
> Some hardware (vmware's virtual in particular) may not be able to pick up the
> changes from a bo directly, since the cursor data is sent though the command
> str
On 11/04/2011 03:36 PM, Ilija Hadzic wrote:
>
>
> On Fri, 4 Nov 2011, Thomas Hellstrom wrote:
>
>> Hi.
>>
>> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR
>> iotcl:
>>
>> Some hardware (vmware's virtual in particular) may not be able to
>> pick up the changes from a bo direct
On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote:
> Hi.
>
> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl:
>
> Some hardware (vmware's virtual in particular) may not be able to
> pick up the changes from a bo directly, since the cursor data is
> sent tho
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #6 from DoTheDog 2011-11-04 08:37:52
PDT ---
Same issue here on the same hardward Sony Vaio VPCZ21 Power Media Dock. The USB
and disk drive work. Just not the ATI video.
DoTheDog
--
Configure bugmail: https://bugs.freedesktop.org/
(cc'ing David Airlie and dri-devel)
Hello, the original thread can be read from
http://thread.gmane.org/gmane.linux.kernel/1209587
Full sysrq-t output at
http://article.gmane.org/gmane.linux.kernel/1211256
So, the problem is that after a seemingly unreated update to input
serio driver (con
https://bugs.freedesktop.org/show_bug.cgi?id=40034
--- Comment #6 from Lauri Kasanen 2011-11-04 09:27:15
PDT ---
This bug doesn't seem to affect r700 - at least my HD4350 works perfectly with
all effects on current master (7.12-devel (git-f800a29))
--
Configure bugmail: https://bugs.freedeskto
Hi all,
I tried to create/pin ring BO in VRAM instead of GTT to debug some
ring-related problems. After I did this, it rendered a black screen in
X (on a X86 RS780E board), but radeon.test passed.
'ps aux' shows X uninterruptibly sleeps on radeon.
Curious why this does not work?
Regards,
-- Ch
mainline git.
Let me know if there is any patch that I can test.
Thanks,
Daniel
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: lspci-v-x20.txt
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2004/bad8064e/attachment.txt>
This patch is preparing multiple display controllers, FIMD and HDMI.
- added padding into ioctl structure to be 64 bit align
- added kms poll to handle hpd event
- fixed converting between display mode and timing
- fixed connector and crtc callbacks to call proper display driver
- code clean
based
missing members are added into converting function between timing and display
mode and refresh rate of display mode is calculated by drm mode function.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c |9 -
1 files changed,
From: Inki Dae
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
include/drm/exynos_drm.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/drm/exynos_drm.h b/include/drm/exynos_drm.h
index 874c4d2..1d161cb 100644
--- a/include/drm/exynos_drm.h
+++ b/incl
From: Joonyoung Shim
during recreating exynos_drm_fbdev as a new display device probes,
fb_helper is reinitialized but kernel fb is not changed
so kernel_fb_list should be restored after fb_helper is reinitialized.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm
hdmi display in exynos supports hotplug event and interlace scan mode
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector
crtc dpms is called as destroying attached fb so dpms off sould be processed.
crtc dpms also can be called after crtc is detached from encoder so pipe value
of manager is used to find display controller for this case
Signed-off-by: Seung-Woo Kim
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Pa
From: Inki Dae
connector contains some contents for display controller so the connector also
should be able to access contoroller through manager.
Signed-off-by: Inki Dae
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 38 ++
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_encoder.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 4092f41..2d7a03
From: Inki Dae
exynos_drm_display has function pointes so exynos_drm_display_ops is better
to describe.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 29 +
drivers/gpu/drm/exynos/exynos_drm_drv.h |4
drm_framebuffer already has width and height so they are meaningless as
parameters when updating fb_info.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a
this patch adds kms poll infrastructure to handle hotplug detection event
Signed-off-by: Seung-Woo Kim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |5 +
drivers/gpu/drm/exynos/exynos_drm_fb.c | 12
2 files changed, 17 insertions(+), 0 deletio
Hi everyone,
This patch is hdmi display support for exynos drm driver.
This patch is based on previous exynos drm patch and here is link for it:
https://lkml.org/lkml/2011/11/4/115
There is already v4l2 based exynos hdmi driver in drivers/media/video/s5p-tv
and some low level code is already in
On Fri, Nov 04, 2011 at 09:14:31AM -0700, Tejun Heo wrote:
> (cc'ing David Airlie and dri-devel)
>
> Hello, the original thread can be read from
>
> http://thread.gmane.org/gmane.linux.kernel/1209587
>
> Full sysrq-t output at
>
> http://article.gmane.org/gmane.linux.kernel/1211256
>
> So,
On Fri, Nov 4, 2011 at 10:26 AM, Chen Jie wrote:
> Hi all,
>
> I tried to create/pin ring BO in VRAM instead of GTT to debug some
> ring-related problems. After I did this, it rendered a black screen in
> X (on a X86 RS780E board), but radeon.test passed.
> 'ps aux' shows X uninterruptibly sleeps
On Fri, Nov 4, 2011 at 1:34 PM, Andrew Watts wrote:
> On Fri, Nov 04, 2011 at 09:14:31AM -0700, Tejun Heo wrote:
>> Andrew, can you please kill the X server after the hang and see
>> whether that brings the system back? ?I think sshd should still work
>> and if not you can write a script to kill t
On Fri, Nov 04, 2011 at 12:34:58PM -0500, Andrew Watts wrote:
> On Fri, Nov 04, 2011 at 09:14:31AM -0700, Tejun Heo wrote:
> > Andrew, can you please kill the X server after the hang and see
> > whether that brings the system back? I think sshd should still work
> > and if not you can write a scri
This might hide some GPU lockup issue deadlock on resume.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_device.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index c33bc9
On Fri, Nov 04, 2011 at 09:14:31AM -0700, Tejun Heo wrote:
> Andrew, can you please kill the X server after the hang and see
> whether that brings the system back? I think sshd should still work
> and if not you can write a script to kill the X server after 30secs
> after resume (and kill that scr
---
A non-text attachment was scrubbed...
Name: bad-dmesg.txt.gz
Type: application/x-gunzip
Size: 3950 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2004/c0af4707/attachment-0001.bin>
On 11/04/2011 04:34 PM, Daniel Vetter wrote:
> On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote:
>
>> Hi.
>>
>> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl:
>>
>> Some hardware (vmware's virtual in particular) may not be able to
>> pick up the change
On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom
wrote:
> On 11/04/2011 04:34 PM, Daniel Vetter wrote:
>>
>> On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote:
>>
>>>
>>> Hi.
>>>
>>> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl:
>>>
>>> Some hardware (v
On 11/04/2011 11:49 PM, Maarten Maathuis wrote:
> On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom
> wrote:
>
>> On 11/04/2011 04:34 PM, Daniel Vetter wrote:
>>
>>> On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote:
>>>
>>>
Hi.
I have a question ab
On Fri, Nov 04, 2011 at 01:35:53PM -0400, Jerome Glisse wrote:
>
> I need full dmesg
>
> Cheers,
> Jerome
Hi. Just noticed I attached a gzip of my dmesg last time by mistake.
Here goes as text/plain.
~ Andy
-- next part --
[ 237.030115] PM: Marking nosave pages: 0
81 matches
Mail list logo
