Hi Karol,
I don't get what you mean with return due to fallthrough. I mean, I
know what is it, but I don't see how I can do it there.
Moving the check before the switch looks like that:
if (!iccsense)
return 0;
switch (attr) {
case hwmon_power_input:
On 04/13/2017 02:45 AM, Jordan Crouse wrote:
Hey Rob -
Here is the stack of stuff to add the zap shader for msm-next. I left
the code broken out as the first two changes are merged into the device
specific tree and the third one has been seen before so this should
hopefully cut down on confusi
https://bugs.freedesktop.org/show_bug.cgi?id=100681
--- Comment #6 from Michel Dänzer ---
Might be fixed with LLVM r300791.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop
https://bugzilla.kernel.org/show_bug.cgi?id=195465
--- Comment #3 from Michel Dänzer (mic...@daenzer.net) ---
What exactly is the problem? The only suspicious thing in dmesg is the below,
which indicates that the GPU's power management might not be working perfectly:
[ 20.346154] cant't get the
https://bugs.freedesktop.org/show_bug.cgi?id=100726
--- Comment #2 from Michel Dänzer ---
It's unlikely that this is caused by the bisected commit. You'll need to test
longer before declaring a commit as good.
--
You are receiving this mail because:
You are the assignee for the bug.
On 04/20/2017 03:03 AM, Arnd Bergmann wrote:
Without the dependency, we run into a link error:
drivers/gpu/drm/panel/panel-sitronix-st7789v.o: In function `st7789v_probe':
panel-sitronix-st7789v.c:(.text.st7789v_probe+0xc0): undefined reference to
`of_find_backlight_by_node'
Fixes: 7142afb3a18
Hi Arnd,
Thanks for your patch.
On 04/20/2017 02:59 AM, Arnd Bergmann wrote:
The new S6E3HA2 driver fails to link when backlight is disabled:
ERROR: "backlight_device_register"
[drivers/gpu/drm/panel/panel-samsung-s6e3ha2.ko] undefined!
ERROR: "backlight_device_unregister"
[drivers/gpu/drm/p
Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.
I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.
Christoph Hellwig suggested [1] renaming
On 04/19/2017 12:36 PM, Logan Gunthorpe wrote:
Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.
I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code
https://bugs.freedesktop.org/show_bug.cgi?id=100465
--- Comment #26 from Zachary Michaels ---
Also note that forcing VGT_STREAMOUT_SYNC, VGT_STREAMOUT_RESET, or VGT_FLUSH to
be emitted on each call to si_draw_vbo (via si_emit_cache_flush) also appears
to work around the issue, though this has not
https://bugs.freedesktop.org/show_bug.cgi?id=100465
--- Comment #25 from Zachary Michaels ---
These settings reproduce consistently on my W600 test machine:
./thrash -w 1920 -h 1080 -c 3 -t 1000 -m 10
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=100465
--- Comment #24 from Zachary Michaels ---
Hi! There is a stress test here that we have been using to reproduce this
issue: https://github.com/Oblong/thrasher
Enabling debug tracing works around the issue. Specifically, when si_draw_vbo
calls si
On Wed, Apr 12, 2017 at 07:15:26PM +0200, Lucas Stach wrote:
> This adds support for the NLT Technologies NL192108AC18-02D
> 15.6" LVDS FullHD TFT LCD panel, which can be supported
> by the simple panel driver.
>
> Timings are taken from the preliminary datasheet, as a final
> one is not yet avail
On Wed, Apr 12, 2017 at 07:15:25PM +0200, Lucas Stach wrote:
> NLT technologies is the former NEC display business, but changed its
> name to NLT Technologies when forming a joint venture with
> Shenzhen AVIC OPTOELECTRONICS, Ltd.
>
> Signed-off-by: Lucas Stach
> ---
> Documentation/devicetree/b
Hi Arnd,
On 19/04/17 18:59, Arnd Bergmann wrote:
> When the media subsystem is built as a loadable module, a built-in
> DRM driver cannot use the cec notifiers:
>
> drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_remove':
> sti_hdmi.c:(.text.sti_hdmi_remove+0x28): undefined reference to
>
Thanks Vladis!
Reviewed-by: Sinclair Yeh
On Thu, Apr 06, 2017 at 02:33:40PM +0200, Vladis Dronov wrote:
> The 'req->mip_levels' parameter in vmw_gb_surface_define_ioctl() is
> a user-controlled 'uint32_t' value which is used as a loop count limit.
> This can lead to a kernel lockup and DoS. Add
On Wed, Apr 19, 2017 at 10:21 PM, Laurent Pinchart
wrote:
>>
>> This adds a dependency like we have for the other panel drivers.
>
> I believe the dependency should be made optional. DPI panels that don't need
> backlight control should be supported by a kernel that has backlight support
> compile
Hi Arnd,
Thank you for the patch.
On Wednesday 19 Apr 2017 19:59:17 Arnd Bergmann wrote:
> The panel driver gained support for backlight but fails to link now
> when that is disabled:
>
> drivers/gpu/drm/omapdrm/displays/panel-dpi.o: In function
> `panel_dpi_probe_of': panel-dpi.c:(.text.panel_d
On Wed, Apr 19, 2017 at 7:55 PM, Eric Anholt wrote:
> Daniel Vetter writes:
>> On Tue, Apr 18, 2017 at 9:11 PM, Eric Anholt wrote:
>>> The FBDEV initialization would throw an error in dmesg, when we just
>>> want to silently not initialize fbdev on a V3D-only VC4 instance.
>>>
>>> Signed-off-by:
On 20 April 2017 at 04:42, Dave Airlie wrote:
> On 19 April 2017 at 22:07, Christian König wrote:
>> Am 13.04.2017 um 03:41 schrieb Dave Airlie:
>>>
>>> Okay I've taken Chris's suggestions to heart and reworked things
>>> around a sem_file to see how they might look.
>>>
>>> This means the drm_sy
On Wed, Apr 19, 2017 at 9:11 PM, Arnd Bergmann wrote:
> When CONFIG_THERMAL is enabled as a loadable module, and etnaviv is
> built-in, we get a link error:
>
> drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind':
> etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0x34): undefined reference
https://bugs.freedesktop.org/show_bug.cgi?id=100726
--- Comment #1 from hiwatari.se...@gmail.com ---
Created attachment 130926
--> https://bugs.freedesktop.org/attachment.cgi?id=130926&action=edit
Short video showing the issue
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freedesktop.org/show_bug.cgi?id=100726
Bug ID: 100726
Summary: [REGRESSION][BISECTED] Severe flickering with an R9
290
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
On 19 April 2017 at 22:07, Christian König wrote:
> Am 13.04.2017 um 03:41 schrieb Dave Airlie:
>>
>> Okay I've taken Chris's suggestions to heart and reworked things
>> around a sem_file to see how they might look.
>>
>> This means the drm_syncobj are currently only useful for semaphores,
>> the
On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador
wrote:
> This patch creates a special group attributes for attrs like "*auto_point*".
> We check if we have support for them, and if we do, we gather them all in
> an attribute_group's structure which is the parameter regarding special groups
> of hw
When IOMMU_IOVA is not built-in but host1x is, we get a link error:
drivers/gpu/host1x/dev.o: In function `host1x_remove':
dev.c:(.text.host1x_remove+0x50): undefined reference to `put_iova_domain'
drivers/gpu/host1x/dev.o: In function `host1x_probe':
dev.c:(.text.host1x_probe+0x31c): undefined re
When dma_addr_t and phys_addr_t are not the same size, we get a warning
from the dma_alloc_wc function:
drivers/gpu/host1x/cdma.c: In function 'host1x_pushbuffer_init':
drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of 'dma_alloc_wc'
from incompatible pointer type [-Werror=incompatibl
Quoting Rob Clark (2017-04-18 11:27:14)
> On Tue, Apr 18, 2017 at 1:32 PM, Emil Velikov
> wrote:
> > On 18 April 2017 at 16:48, Rob Clark wrote:
> >> On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia
> >> wrote:
> >>> Hi there
> >>>
> >>> I am Raghav Jajodia, an Engineering student from India. Wh
On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador
wrote:
> +static char *input_label = "GPU core";
This needs to be static const char input_label[] = "GPU core";
or at least static const char *const input_label = "GPU core";
-ilia
___
dri-devel mailin
Got it, I'll make a v3 with that line in all patches.
Thanks!
On 19 April 2017 at 20:11, Ilia Mirkin wrote:
> All kernel patches must have a Signed-off-by: $user. See
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
>
>
When CONFIG_THERMAL is enabled as a loadable module, and etnaviv is
built-in, we get a link error:
drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind':
etnaviv_gpu.c:(.text.etnaviv_gpu_bind+0x34): undefined reference to
`thermal_of_cooling_device_register'
etnaviv_gpu.c:(.text.e
All kernel patches must have a Signed-off-by: $user. See
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador
wrote:
> This is a preparation for the next patches. It just adds th
Without the dependency, we run into a link error:
drivers/gpu/drm/panel/panel-sitronix-st7789v.o: In function `st7789v_probe':
panel-sitronix-st7789v.c:(.text.st7789v_probe+0xc0): undefined reference to
`of_find_backlight_by_node'
Fixes: 7142afb3a186 ("drm/panel: Add driver for sitronix ST7789V
The new S6E3HA2 driver fails to link when backlight is disabled:
ERROR: "backlight_device_register"
[drivers/gpu/drm/panel/panel-samsung-s6e3ha2.ko] undefined!
ERROR: "backlight_device_unregister"
[drivers/gpu/drm/panel/panel-samsung-s6e3ha2.ko] undefined!
This adds a Kconfig dependency like we
The panel driver gained support for backlight but fails to link now
when that is disabled:
drivers/gpu/drm/omapdrm/displays/panel-dpi.o: In function `panel_dpi_probe_of':
panel-dpi.c:(.text.panel_dpi_probe_of+0xe8): undefined reference to
`of_find_backlight_by_node'
This adds a dependency like w
Daniel Vetter writes:
> On Tue, Apr 18, 2017 at 9:11 PM, Eric Anholt wrote:
>> The FBDEV initialization would throw an error in dmesg, when we just
>> want to silently not initialize fbdev on a V3D-only VC4 instance.
>>
>> Signed-off-by: Eric Anholt
>
> Hm, this shouldn't be an error really, yo
https://bugzilla.kernel.org/show_bug.cgi?id=195465
--- Comment #2 from Hugo Andrade (hugo.s...@gmail.com) ---
Created attachment 255929
--> https://bugzilla.kernel.org/attachment.cgi?id=255929&action=edit
lshw
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugzilla.kernel.org/show_bug.cgi?id=195465
--- Comment #1 from Hugo Andrade (hugo.s...@gmail.com) ---
Created attachment 255927
--> https://bugzilla.kernel.org/attachment.cgi?id=255927&action=edit
Lspci
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
On 04/19/2017 05:07 AM, Christian König wrote:
Am 13.04.2017 um 03:41 schrieb Dave Airlie:
Okay I've taken Chris's suggestions to heart and reworked things
around a sem_file to see how they might look.
This means the drm_syncobj are currently only useful for semaphores,
the flags field could be
https://bugzilla.kernel.org/show_bug.cgi?id=195465
Bug ID: 195465
Summary: AMD Hybrid graphic dont work, R7 M260/M265 (Topaz)
Product: Drivers
Version: 2.5
Kernel Version: 4.9.0-2-amd64
Hardware: x86-64
OS: Linux
When the media subsystem is built as a loadable module, a built-in
DRM driver cannot use the cec notifiers:
drivers/gpu/drm/sti/sti_hdmi.o: In function `sti_hdmi_remove':
sti_hdmi.c:(.text.sti_hdmi_remove+0x28): undefined reference to
`cec_notifier_set_phys_addr'
sti_hdmi.c:(.text.sti_hdmi_remove
When the media subsystem is built as a loadable module, a built-in
DRM driver cannot use the cec notifiers:
drivers/gpu/drm/exynos/exynos_hdmi.o: In function `hdmi_get_modes':
exynos_hdmi.c:(.text.hdmi_get_modes+0x80): undefined reference to
`cec_notifier_set_phys_addr_from_edid'
drivers/gpu/drm/
Minor nits, otherwise the vmwgfx part,
Reviewed-by: Sinclair Yeh
On Tue, Apr 18, 2017 at 06:17:00PM -0600, Logan Gunthorpe wrote:
> Seeing the kunmap_atomic dma_buf_op shares the same name with a macro
s^
> in higmem.h, the former can be aliased if any dma-b
https://bugs.freedesktop.org/show_bug.cgi?id=92258
--- Comment #49 from russianneuroman...@ya.ru ---
By the way, seems like issue is much easier to reproduce with Steam desktop
notifications. Try to download something small, and it will show "download
completed" notification, or ask someone to sen
From: Clint Taylor
Adding DPCD register definitions from the DP 1.3 specification for CEC
over AUX support.
Signed-off-by: Clint Taylor
---
include/drm/drm_dp_helper.h | 59 +++
1 file changed, 59 insertions(+)
diff --git a/include/drm/drm_dp_helper.h
drm-tip/drm-tip boot: 114 boots: 3 failed, 109 passed with 2 offline
(v4.11-rc7-1959-g3ae84ad0eb45)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1959-g3ae84ad0eb45/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11
Regards
Shashank
On 4/8/2017 11:13 PM, Emil Velikov wrote:
Hi Shashank,
On 7 April 2017 at 17:39, Shashank Sharma wrote:
+ u64 hdmi_420_cap_map = connector->display_info.hdmi.ycbcr420_vcb_map;
for (i = 0; i < len; i++) {
struct drm_display_mode *mode;
Regards
Shashank
On 4/10/2017 3:17 PM, Andrzej Hajda wrote:
On 07.04.2017 18:39, Shashank Sharma wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per
Regards
Shashank
On 4/12/2017 3:19 PM, Jose Abreu wrote:
Hi Shashank,
On 07-04-2017 17:39, Shashank Sharma wrote:
HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.
As this patch series is adding support for HDMI o
Hello Jose,
Sorry for delay in response, I was on vacation.
Please find my comments inline.
Regards
Shashank
On 4/12/2017 3:28 PM, Jose Abreu wrote:
Hi Shashank,
On 07-04-2017 17:39, Shashank Sharma wrote:
HDMI displays can support various output types, based on
the color space and subsampli
On Thu, Apr 13, 2017 at 11:15:37AM +0200, Maarten Lankhorst wrote:
> This is required to for i915 to convert connector properties to atomic.
>
> Changes since v1:
> - Add docbook info. (danvet)
> - Change picture_aspect_ratio to enum hdmi_picture_aspect.
>
> Signed-off-by: Maarten Lankhorst
> Cc
https://bugs.freedesktop.org/show_bug.cgi?id=92258
--- Comment #48 from russianneuroman...@ya.ru ---
Issue is still reproducible with Linux 4.11rc7 and Mesa 17.2-git.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-deve
https://bugs.freedesktop.org/show_bug.cgi?id=100591
--- Comment #7 from Alex Deucher ---
https://patchwork.kernel.org/patch/9669611/
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.fr
On Tue, 11 Apr 2017, Kees Cook wrote:
> While highly unlikely, this makes sure that the string built from
> engine names won't be processed as a format string.
>
> Signed-off-by: Kees Cook
Pushed to drm-intel-next-queued, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_hang
On Wed, Apr 19, 2017 at 01:34:34PM +0200, Boris Brezillon wrote:
On Wed, 19 Apr 2017 10:51:23 +0100
Brian Starkey wrote:
[snip]
Could you expand a bit on how you think planes fit better?
Just had the impression that the writeback feature was conceptually
closer to a plane object (which is
Hi Daniel,
On Wednesday 19 Apr 2017 10:36:55 Daniel Vetter wrote:
> On Tue, Apr 18, 2017 at 11:27:14AM -0700, Laura Abbott wrote:
> > Most of the items have been taken care of by a clean up series. Remove
> > the completed items and add a few new ones.
> >
> > Signed-off-by: Laura Abbott
> > ---
drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 45 warnings
(v4.11-rc7-1959-g3ae84ad0eb45)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1959-g3ae84ad0eb45/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc7-1959-g3ae84ad0eb45
Git Commit: 3ae
Hi,
> > >> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses
> > >> e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses
> > >> native endian packed colour values.
> > >
> > > Same is true for DRM_IOCTL_MODE_ADDFB, with depth/bpp 24/32 you'll get
> > > D
Am 13.04.2017 um 03:41 schrieb Dave Airlie:
Okay I've taken Chris's suggestions to heart and reworked things
around a sem_file to see how they might look.
This means the drm_syncobj are currently only useful for semaphores,
the flags field could be used in future to use it for other things,
and
https://bugs.freedesktop.org/show_bug.cgi?id=100712
--- Comment #5 from Julien Isorce ---
(In reply to Michel Dänzer from comment #4)
> (In reply to Julien Isorce from comment #0)
> > In kernel radeon_object.c::radeon_bo_list_validate, once "bytes_moved >
> > bytes_moved_threshold" is reached (th
Am 13.04.2017 um 03:41 schrieb Dave Airlie:
From: Dave Airlie
This just splits out a common base object to be shared
between sync_file and sem_files.
I don't think I like that approach.
A good argument of using sync_file instead of self coding it was to be
able to be able to use the resulti
drm-tip/drm-tip boot: 86 boots: 3 failed, 81 passed with 2 offline
(v4.11-rc7-1958-g05040c47d415)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1958-g05040c47d415/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-r
On Wed, 19 Apr 2017 10:51:23 +0100
Brian Starkey wrote:
> On Tue, Apr 18, 2017 at 09:57:17PM +0200, Boris Brezillon wrote:
> >Hi Brian,
> >
> >On Tue, 18 Apr 2017 18:34:43 +0100
> >Brian Starkey wrote:
> >
> >> >> @@ -214,6 +214,19 @@ struct drm_connector_state {
> >> >> struct drm_enc
https://bugs.freedesktop.org/show_bug.cgi?id=96296
--- Comment #7 from ricardo.riba...@gmail.com ---
Created attachment 130914
--> https://bugs.freedesktop.org/attachment.cgi?id=130914&action=edit
AMD PALM (DRM 2.49.0 / 4.10.0-qtec-standard, LLVM 4.0.1 + MESA 17.0.3
--
You are receiving this m
https://bugs.freedesktop.org/show_bug.cgi?id=96296
--- Comment #6 from ricardo.riba...@gmail.com ---
Using llvm 4.0.1 and the latest git commit from libclc (
17648cd846390e294feafef21c32c7106eac1e24 ):
I am getting a cpu endless loop with clpeak, fixable with ctrl+c.
Other samples, such as Matri
drm-tip/drm-tip boot: 16 boots: 2 failed, 14 passed
(v4.11-rc7-1957-g06b36a78fe41)
Full Boot Summary:
https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1957-g06b36a78fe41/
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1957-g06b36a
On Tue, Apr 18, 2017 at 09:57:17PM +0200, Boris Brezillon wrote:
Hi Brian,
On Tue, 18 Apr 2017 18:34:43 +0100
Brian Starkey wrote:
>> @@ -214,6 +214,19 @@ struct drm_connector_state {
>>struct drm_encoder *best_encoder;
>>
>>struct drm_atomic_state *state;
>> +
>> + /**
>
On Tue, Apr 18, 2017 at 11:27:14AM -0700, Laura Abbott wrote:
> Most of the items have been taken care of by a clean up series. Remove
> the completed items and add a few new ones.
>
> Signed-off-by: Laura Abbott
> ---
> drivers/staging/android/TODO | 21 -
> 1 file changed,
On Tue, Apr 18, 2017 at 11:27:12AM -0700, Laura Abbott wrote:
> ion_handle was introduced as an abstraction to represent a reference to
> a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf
> emerged as the preferred standard for use in the kernel. This has made
> the ion_h
On Tue, Apr 18, 2017 at 11:27:07AM -0700, Laura Abbott wrote:
> Several of the Ion ioctls were designed in such a way that they
> necessitate compat ioctls. We're breaking a bunch of other ABIs and
> cleaning stuff up anyway so let's follow the ioctl guidelines and clean
> things up while everyone
drm-tip/drm-tip build: 207 builds: 0 failed, 207 passed, 45 warnings
(v4.11-rc7-1958-g05040c47d415)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1958-g05040c47d415/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc7-1958-g05040c47d415
Git Commit: 050
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45
warnings (v4.11-rc7-1957-g06b36a78fe41)
Full Build Summary:
https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc7-1957-g06b36a78fe41/
Tree: drm-tip
Branch: drm-tip
Git Describe: v4.11-rc7-1957-g06b36a78fe41
Git
https://bugs.freedesktop.org/show_bug.cgi?id=100591
--- Comment #6 from splitt ---
Same hang here, same CPU : booting with kernel parameter amd_iommu=off solved
the problem.
For more details, please search for stoney patch disable ATS.
++
--
You are receiving this mail because:
You are the ass
On Wed, 19 Apr 2017 10:01:47 +0900
Michel Dänzer wrote:
> On 18/04/17 07:14 PM, Gerd Hoffmann wrote:
> > Hi,
> >
> >>> Quite true that this proves nothing. However one should note that
> >>> fbcon -> fbdev works,
> >>
> >> BTW, this supports Gerd's patch, since the KMS fbdev emulation code
74 matches
Mail list logo
