Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 38491 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/ccebfb1e/attachment-0001.obj>
On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
> + cec->adap = cec_create_adapter(&s5p_cec_adap_ops, cec,
> + CEC_NAME, CEC_CAP_STATE |
> + CEC_CAP_PHYS_ADDR | CEC_CAP_LOG_ADDRS | CEC_CAP_IO |
> + CEC_CAP_IS_SOURCE,
> + 0, THIS_MODU
On Fri, Oct 2, 2015 at 5:56 PM, Sudip Mukherjee
wrote:
> On Thu, Oct 01, 2015 at 07:07:33PM +0200, Patrik Jakobsson wrote:
>> On Wed, Sep 30, 2015 at 8:12 AM, Sudip Mukherjee
>> wrote:
>> > On Tue, Sep 29, 2015 at 03:20:35PM +0200, Patrik Jakobsson wrote:
>> >> On Thu, Sep 24, 2015 at 5:57 PM, Su
ktop.org/archives/dri-devel/attachments/20151006/19b3edcf/attachment-0001.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/7912d718/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/6b72f932/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/e12f1107/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/ee970b69/attachment-0001.html>
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/9f09ac85/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/a00035b0/attachment.html>
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/3273a090/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/d0eab21a/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/1aef3b15/attachment.html>
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/c74bb3d1/attachment-0001.html>
I have mind few uses cases:
- the basic one when an HW device need contiguous memory.
- I have a device that could not cross some memory boundaries so I
need a specific allocator for it.
- when allocating memory for security some platform have address
constraints or need to allocate memory in speci
On Fri, Aug 14, 2015 at 06:50:15PM +0200, Lukas Wunner wrote:
> Originally by Seth Forshee , 2012-10-04:
> During graphics driver initialization it's useful to be able to mux
> only the DDC to the inactive client in order to read the EDID. Add
> a switch_ddc callback to allow capable ha
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/38dc2519/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/0ffdefd6/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/d7ec3fd1/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/95a18707/attachment.html>
iving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/0e7aedc4/attachment.html>
iving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/0e2ea7f7/attachment.html>
s/dri-devel/attachments/20151006/8b6e27ed/attachment.html>
tly but in the past with
your options they would end up in /usr/etc and not get used so add -
--sysconfdir=/etc
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.o
i386 Packages
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/31abe38d/attachment-0001.html>
Thanks for your review I will add a lock in smaf_handle structure.
One of the goal of smaf is to create a standard kernel API to allocate
and secure buffers to avoid forking
while implementing buffer securing feature.
One concern about ION is that the selection of the heap is done by userland
so
s?
> >> Or even docs separately?
> >
> > This should be three patches: the vendor prefix is usually a separate
> > patch and needs an Acked-by from one of the device tree bindings
> > maintainers. The binding itself should also be a separate patch and the
> > driver changes should come last.
>
> I will split the patch and first submit DT binding docs.
Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/83f999b6/attachment.sig>
reset and reboot. :(
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/fc3ca57c/attachment.html>
errors.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/e1549d72/attachment.html>
We are currently restricted when it comes to supporting DSI on devices
that have a non-DSI control bus. For example, DSI encoder chips are
available in the market that are configured via i2c. Configuring their
registers via DSI bus is either optional or not available at all.
These devices still ne
Simplify the mipi dsi device creation process. device_initialize and
device_add don't need to be called separately when creating
mipi_dsi_device's. Use device_register instead to simplify things.
Create a helper function mipi_dsi_device_new which takes in struct
mipi_dsi_device_info and mipi_dsi_h
Add a device name field in mipi_dsi_device. This name is different from
the actual dev name (which is of the format "hostname.reg"). When the
device is created via DT, this name is set to the modalias string.
In the non-DT case, the driver creating the DSI device provides the
name by populating a f
We don't check whether a previously registered mipi_dsi_device under the
same host shares the same virtual channel.
Before registering, check if any of the registered devices doesn't
already have the same virtual channel.
This wasn't crucial when all the devices under a host were populated via
DT
A driver calling mipi_dsi_device_new might want to unregister the device
once it's done. It might also require it in an error handling path in
case something didn't go right.
When the dsi host driver calls mipi_dsi_host_unregister, the devices
created by both DT and and without DT will be removed.
mipi_dsi_devices are inherently aware of their host because they
share a parent-child hierarchy in the device tree.
Non-dsi drivers that create a dummy dsi device don't have this data.
In order to get this information, they require to a phandle to the dsi
host in the device tree.
Maintain a list
(16): error: no function with name 'texelFetch2DOffset'
0:526(16): error: no function with name 'texelFetch2DOffset'
I noticed it reports GPU: Gallium 0.4 on AMD HAWAII (DRM 2.43.0, LLVM 3.6.2)
3.0 Mesa 11.1.0-devel (git-e413d2f 2015-09-28 vivid-oibaf-ppa) with 256 Mb
video-memory (should be 8Gb)...
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/8494d4da/attachment-0001.html>
ultiple reported errors, but also that it reports using:
GPU: Gallium 0.4 on AMD HAWAII (DRM 2.43.0, LLVM 3.6.2) 3.0 Mesa 11.1.0-devel
(git-e413d2f 2015-09-28 vivid-oibaf-ppa)
This is not the one I've built, is it ? - should be LLVM 3.8-dev 4.1 Mesa
11.0.2 ?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/a8226ec7/attachment.html>
job for coccinelle. I wonder if it has a way to figure out which
> functions are plugged into these hooks and do the job entirely
> automatically...
Actually the above-mentioned patch updated drivers as well, otherwise
there would've been tons of warnings from mismatched types.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/f75309f1/attachment.sig>
9 int (*detach)(struct
mipi_dsi_host *host,
068a0023 Andrzej Hajda 2013-12-04 90 struct
mipi_dsi_device *dsi);
068a0023 Andrzej Hajda 2013-12-04 91 ssize_t (*transfer)(struct
mipi_dsi_host *host,
ed6ff40e Thierry Reding 2014-08-05 92
Hi Daniel,
thank you for taking a look at the patch set and shepherding this
through the review process.
On Tue, Oct 06, 2015 at 09:27:24AM +0200, Daniel Vetter wrote:
> On Fri, Aug 14, 2015 at 06:50:15PM +0200, Lukas Wunner wrote:
> > Don't lock vgasr_mutex in _lock_ddc() / _unlock_ddc(), it
pefully the reboots.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/43ae9ce6/attachment.html>
On Thu, Sep 24, 2015 at 06:35:31PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> This continues the pattern started in commit cc1ef118fc09 ("drm/irq:
> Make pipe unsigned and name consistent"). This is applied to the public
> APIs and driver callbacks, so pretty much all drivers need to
isted.
DRM and LLVM are old as IIRC oibaf doesn't do git versions of those.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/a
In addition to the last-in/first-out stack for accessing drm_mm nodes,
we occasionally and in the future often want to find a drm_mm_node by an
address. To do so efficiently we need to track the nodes in an interval
tree - lookups for a particular address will then be O(lg(N)), where N
is the numbe
On Tue, Oct 06, 2015 at 12:10:48PM +0200, Lukas Wunner wrote:
> Hi Daniel,
>
> thank you for taking a look at the patch set and shepherding this
> through the review process.
>
> On Tue, Oct 06, 2015 at 09:27:24AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 14, 2015 at 06:50:15PM +0200, Lukas Wun
On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
> In addition to the last-in/first-out stack for accessing drm_mm nodes,
> we occasionally and in the future often want to find a drm_mm_node by an
> address. To do so efficiently we need to track the nodes in an interval
> tree - lookup
On Tue, Oct 06, 2015 at 01:11:56PM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
> > In addition to the last-in/first-out stack for accessing drm_mm nodes,
> > we occasionally and in the future often want to find a drm_mm_node by an
> > address. To do s
tachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/61e4bdba/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=105581
Bug ID: 105581
Summary: amdgpu: r9 380 Dual Monitor Setup: rotation not
working
Product: Drivers
Version: 2.5
Kernel Version: 4.2.2, 4.3-rc3, 4.3-rc4
Hardware: Intel
On Tue, Oct 06, 2015 at 12:19:43PM +0100, Chris Wilson wrote:
> On Tue, Oct 06, 2015 at 01:11:56PM +0200, Daniel Vetter wrote:
> > On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote:
> > > In addition to the last-in/first-out stack for accessing drm_mm nodes,
> > > we occasionally and in
Hi,
I had some time during the recent local holidays, so I thought I
improve the hsakmt library in terms of releases:
1. I added automake/autoconf files to standardize the package to be
created using configure/make/make install.
2. I created a very simple scheme of numbering so we could track re
https://bugzilla.kernel.org/show_bug.cgi?id=105581
--- Comment #1 from f.otti at gmx.at ---
Created attachment 189571
--> https://bugzilla.kernel.org/attachment.cgi?id=189571&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/585e9368/attachment.html>
On 10/5/2015 7:06 PM, Kristian Høgsberg wrote:
> On Mon, Oct 5, 2015 at 7:03 AM, Michel Thierry
> wrote:
>> On 9/14/2015 2:54 PM, MichaÅ Winiarski wrote:
>>>
>>> On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote:
Gen8+ supports 48-bit virtual addresses, but some objects m
On 2015/10/5 18:03, Joerg Roedel wrote:
> Hi Jiang,
>
> On Sat, Oct 03, 2015 at 03:36:35PM +0800, Jiang Liu wrote:
>> So to summary, I think we only need following change to fix the
>> regression:
>> int pcibios_alloc_irq(struct pci_dev *dev)
>> {
>> +if (pci_dev_msi_enabled(dev))
>> +
On Tue, 6 Oct 2015 11:23:03 +0200
Arnaud Pouliquen wrote:
[snip]
> As API is defined in DRM, it seems more logical to match it with the one
> defined for video. From my windows, i didn't see any blocking point to
> connect codec callback with this API.
> But anyway, this API is not freezed
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20151006/02056ffe/attachment.html>
vel/attachments/20151006/61de75da/attachment.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/a97cb8e5/attachment.html>
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/afa5a48e/attachment.html>
On 10/06/15 12:23, Arnaud Pouliquen wrote:
> Hello Jyri,
>
> Thanks your feedback, my answers in line
>
>
> On 10/05/2015 03:27 PM, Jyri Sarha wrote:
>> On 10/01/15 19:50, Arnaud Pouliquen wrote:
>>>
>>> Version 2:
>>> This version integrates missing features upgraded to be aligned when
>>> possibl
We are allocating backing using psbfb_alloc() and so
backing->stolen is always true. So we were freeing backing two times.
Moreover if we follow the execution path then we should be freeing
backing after we have released the helper. So remove the one which frees
backing before the helper is release
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/4fc2bdd4/attachment.html>
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/fc4c9b8a/attachment.html>
On Mon, Sep 07, 2015 at 03:44:36PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> The added HDMI CEC framework provides a generic kernel interface for
> HDMI CEC devices.
>
> Signed-off-by: Hans Verkuil
> [k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil]
> [k.debski at s
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/851f40b5/attachment.html>
On Sat, Aug 8, 2015 at 1:03 PM, Russell King
wrote:
> Use a function to convert the sync pin to a bit mask for the DI_GENERAL
> register, and move this out of the interlace/non-interlace path to the
> common path.
>
> Signed-off-by: Russell King
Reviewed-by: Fabio Estevam
On Sat, Aug 8, 2015 at 1:03 PM, Russell King
wrote:
> The support for interlaced video modes seems to be broken; we don't use
> anything other than the vtotal/htotal from the timing information to
> define the various sync counters.
>
> Freescale patches for interlaced video support contain an alt
On Sat, Aug 8, 2015 at 1:03 PM, Russell King
wrote:
> Add support for interlaced video modes to the dw_hdmi bridge. This
> mainly involves halving the vertical parameters to be programmed into
> the bridge registers, and setting the interlace_allowed connector flag.
>
> This brings working 1080i
On Sat, Aug 8, 2015 at 1:04 PM, Russell King
wrote:
> When connected to HDMI sources, some DVI monitors de-assert their HPD
> signal and TDMS loads for one seconds every four seconds when there is
> no signal present on the connection.
>
> Unfortunately, this behaviour is indistinguishable from a
On Sat, Aug 8, 2015 at 1:04 PM, Russell King
wrote:
> HDMI sinks are permitted to de-assert and re-assert the HPD signal to
> indicate that their EDID has been updated, which may not involve a
> change of video information.
>
> An example of where such a situation can arise is when an AV receiver
On Mon, Sep 07, 2015 at 03:44:35PM +0200, Hans Verkuil wrote:
> From: Kamil Debski
>
> Add handling of remote control events coming from the HDMI CEC bus.
> This patch includes a new keymap that maps values found in the CEC
> messages to the keys pressed and released. Also, a new protocol has
> b
On Sat, Aug 8, 2015 at 1:10 PM, Russell King
wrote:
> Add ALSA based HDMI AHB audio driver for dw_hdmi. The only buffer
> format supported by the hardware is its own special IEC958 based format,
> which is not compatible with any ALSA format. To avoid doing too much
> data manipulation within th
On Tue, Oct 06, 2015 at 03:07:40PM -0300, Fabio Estevam wrote:
> On Sat, Aug 8, 2015 at 1:10 PM, Russell King
> wrote:
> > Add ALSA based HDMI AHB audio driver for dw_hdmi. The only buffer
> > format supported by the hardware is its own special IEC958 based format,
> > which is not compatible wit
Hi Daniel,
On Tue, Oct 06, 2015 at 01:10:00PM +0200, Daniel Vetter wrote:
> On Tue, Oct 06, 2015 at 12:10:48PM +0200, Lukas Wunner wrote:
> > On Tue, Oct 06, 2015 at 09:27:24AM +0200, Daniel Vetter wrote:
> > > Also while reading the patch I realized that the new lock really protects
> > > hw stat
On Tue, Oct 6, 2015 at 3:18 PM, Russell King - ARM Linux
wrote:
> Sorry, I've been out for most of the day. There's no DT patches required.
>
> The dw_hdmi bridge driver creates its own platform device for the audio,
> which should then bind to the dw_hdmi-ahb-audio driver using normal Linux
> m
On Tue, Oct 06, 2015 at 05:46:02PM +0100, Mark Brown wrote:
> On Tue, Oct 06, 2015 at 06:44:34PM +0300, Jyri Sarha wrote:
> > On 10/06/15 12:23, Arnaud Pouliquen wrote:
>
> > >In a first step, before going deep in discussion on the approach, it
> > >should be interesting to have maintainers feedba
On Tue, Oct 06, 2015 at 03:45:32PM -0300, Fabio Estevam wrote:
> On Tue, Oct 6, 2015 at 3:18 PM, Russell King - ARM Linux
> wrote:
>
> > Sorry, I've been out for most of the day. There's no DT patches required.
> >
> > The dw_hdmi bridge driver creates its own platform device for the audio,
> >
nt was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/5353bd19/attachment.html>
On Tue, Oct 6, 2015 at 3:54 PM, Russell King - ARM Linux
wrote:
> Make sure you have the ALSA config file, as alsalib won't get on
> with dw-hdmi only accepting 24-bit audio without this. A copy is
> attached. It also tells ALSA how to deal with multi-channel audio
> as well.
Thanks, Russell!
https://bugzilla.kernel.org/show_bug.cgi?id=105601
Bug ID: 105601
Summary: drm_wait_vblank log spam with reverse PRIME
(intel+nouveau)
Product: Drivers
Version: 2.5
Kernel Version: 4.2.2
Hardware: x86-64
On Tue, Oct 6, 2015 at 6:52 PM, Pushpal Sidhu wrote:
> Hi All,
>
> I'm attempting to use a standard fb console (using the
> imx6qdl-gw54xx.dtsi), but I find that it only draws to the 1024x768p
> portion of the screen. This is also true when running the userspace
> tool fb-test.
Looking at imx6qdl
The legacy pageflip ioctl calls drm_crtc_check_viewport() to determine
whether the framebuffer being flipped is big enough to fill the display
it is being flipped to. However some drivers support "windowing" of
their primary planes (i.e., a primary plane that does not cover the
entire CRTC dimensi
From: Jan Kara
Hello,
Now when the usage of get_user_pages() in media drivers got cleaned up, here
comes a series which removes knowledge about mmap_sem from a couple of other
drivers. Patches are trivial and standalone but please check, they are only
compile tested. If you are OK with them, e
From: Jan Kara
Convert __i915_gem_userptr_get_pages_worker() to use
get_user_page_unlocked() so that we don't unnecessarily leak knowledge of
mm locking into driver code.
CC: Daniel Vetter
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
Signed-off-by: Jan Kara
---
drivers/gpu/drm/i91
Hi,
> Looks like she installed some tool that attempts to change the power
> state via sysfs during init which could happen before the driver has
> finished loading.
that was probably me, installing the "tlp" thinkpad tool remotely.
Thanks for pointing me in the right direction: disabling solved it
Hi,
This issue is still present in 4.3-rc4.
On 9/24/15, Nick Bowler wrote:
> Testing out 4.3-rc2, first thing I notice is that the VGA output is
> not working. Specifically, the display is continuously powering on
> and off -- at no point is any image visible on the screen (I am expecting
> to
On Tue, Oct 6, 2015 at 3:16 PM, Fabio Estevam wrote:
> On Tue, Oct 6, 2015 at 6:52 PM, Pushpal Sidhu wrote:
>> Hi All,
>>
>> I'm attempting to use a standard fb console (using the
>> imx6qdl-gw54xx.dtsi), but I find that it only draws to the 1024x768p
>> portion of the screen. This is also true w
Hello Jyri,
Thanks your feedback, my answers in line
On 10/05/2015 03:27 PM, Jyri Sarha wrote:
> On 10/01/15 19:50, Arnaud Pouliquen wrote:
>>
>> Version 2:
>> This version integrates missing features upgraded to be aligned when possible
>> with patch set:
>> [PATCH RFC v4 0/8] Implement generic
--- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151006/07dfbcf3/attachment-0001.sig>
Hi All,
I'm attempting to use a standard fb console (using the
imx6qdl-gw54xx.dtsi), but I find that it only draws to the 1024x768p
portion of the screen. This is also true when running the userspace
tool fb-test.
When I $(cat /sys/class/graphics/fb0/modes), I see only the 1024x768p
resolution th
From: Jan Kara
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
Signed-off-by: Jan Kara
---
drivers/gpu/drm/via/via_dmablit.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/via/via_dmablit.c
b/drivers/gpu/drm/via/via_dmablit.c
index d0c
Hi,
I have a NEC EA244WMi monitor connected to an Asus P8H77-V
mainboard with Ivy Bridge Core i5-3550 via DVI.
If DPMS suspend is enabled (by xscreensaver, or for testing by
"xset dpms force off/suspend/standby"), the monitor
enters standby mode but wakes up every 10...30 seconds for
6 seconds to
On Tue, Oct 6, 2015 at 11:10 AM, Johannes Stezenbach wrote:
> Hi,
>
> I have a NEC EA244WMi monitor connected to an Asus P8H77-V
> mainboard with Ivy Bridge Core i5-3550 via DVI.
> If DPMS suspend is enabled (by xscreensaver, or for testing by
> "xset dpms force off/suspend/standby"), the monitor
94 matches
Mail list logo