und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
munikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
if the user already enabled virtio in the config.
This change didn't cause any changes in the .config after menuconfig run,
so we should be completely safe here.
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/gpu/drm/virtio/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1
Hello folks,
could anybody please give me some more insight, how switching
from X to console (ctrl+alt+f*) actually works ?
Who catches the keypress event and initiates the VT switch ?
The Xserver ? Could this be done in the kernel (eg. when Xserver
is hanging) ?
--mtx
--
Enrico Weigelt
precisely
waiting for some changing), that's causing the soft lockup. (maybe too
big timeout ?)
Oh! By the way, the network card r8169 are work wonderful!
Didn't you say (above) that it does not work ?
Or is it just an immediate fail and later comes back ?
--mtx
--
Enrico Weigelt, metux
Signed-off-by: Enrico Weigelt, metux IT consult
---
drivers/video/fbdev/Kconfig | 288 +++---
drivers/video/fbdev/mmp/Kconfig | 6 +-
drivers/video/fbdev/omap/Kconfig | 20 +-
drivers/video/fbdev/omap2/omapfb/Kconfig
On 05.08.2016 10:15, Daniel Vetter wrote:
Hi,
> There's a driver cap DRM_CAP_DUMB_PREFER_SHADOW for this. If set,
> render into a shadow buffer and copy over in bursts, otherwise you
> can assume that the memory is fully cpu cached and fast with random
> access.
h!
nekrad at
On 05.08.2016 01:16, Enrico Weigelt, metux IT consult wrote:
Seems I've been on a completely wrong path - what I'm looking
for is dma-buf. So my idea now goes like this:
* add a new 'virtual GPU' as render node.
* the basic operations are:
-> create a virtual dumb framebuffer (just ins
Hi folks,
when putting pixels into an DRM framebuffer, should I do that in
bursts/blocks instead of byte-per-byte ? (eg. explicitly using
aligned 32bit ops).
--mtx
On 04.08.2016 09:50, Daniel Vetter wrote:
Hi,
> One problem with 2d blitters is that there's no common userspace
> interface, but many: Xrender, hwc, old X drawing api, various attempts by
> khronos to standardize something, cairo, ...
We're talking about userland APIs, not kernel->userland
On 03.08.2016 13:47, Daniel Vetter wrote:
> Because for optimal performance you _must_ supply the commands to the
> kernel in an as close to the format/layout used by the hardware as
> possible. That means no shared command submission of any kind. And the
> other reason is that cache transfers
On 03.08.2016 11:24, Marek Szyprowski wrote:
Hi,
> I'm working now on something similar, but more generic. There is
> already a framework for picture processing (converting, scaling,
> blitting, rotating) in Exynos DRM.
In DRM, not v4l ? Hmm, interesting.
On mx5/mx6 we've got an IPU, which is
On 03.08.2016 05:47, Dave Airlie wrote:
> Because no hw is the same once you go beyond that.
hmm, it doesn't seem to be so extremly different, that we cant
at least abstract some common aspects.
> Video memory size means what? VRAM, GPU accessible system RAM,
> amount of CPU visible VRAM?
On 03.08.2016 01:12, Rob Clark wrote:
Hi,
>> Well, if it already does buffer allocation and mapping (which might
>> also involve copying around phyisical buffers), why not also add
>> copy-between-buffers ?
>
> except "dumb" buffers exist *only* for CPU rendered content, you
> cannot assume
On 02.08.2016 16:04, Daniel Vetter wrote:
> If you mean "add a generic hw-accelerated bitblt operation": This is not
> hw drm works. The generic kms stuff is about display only, with just very
> basic (hence "dumb") buffer allocation support in a generic way.
Well, if it already does buffer
Hi folks,
I'm currently thinking about adding an hw-accelerated bitblt operation.
The idea goes like this:
* we add some bitblt ioctl which copies rects between bo's.
(it also handles memory layouts, pixfmt conversion, etc)
* the driver can decide to let the GPU or IPU do that, if available
*
in parallel.
Unfortunately, I've missed that ... could you please resend you patches?
Boot time reduction is one of the topics on my 2do in several weeks.
cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA
21333 B
Wicht
to linux-media list for review?
>
> No. That's all old stuff and has developed quite a lot since then. We'll
> post new series here on the lists when they are ready for mainline.
Great :)
Do you have them on some public repo, so I can give 'em a try ?
--mtx
--
Enrico Weigelt, metux IT consul
itself) might talk to ipu and vpu ?
>
> Not that I am aware of.
Well, you perhaps can imagine - I dont trust these guys ...
--mtx
ps: greetings from Bene ... you won't guess where I met him
last weekend ;-)
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik o
do you have any idea whether the proprietary driver
(or the gpus itself) might talk to ipu and vpu ?
cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA
21333 B
Wichtiger Hinweis: Diese Nachricht kann vertrauliche
using it w/ gst for video playback, can be directly pass buffers
between VPU, IPU and FB (or let them directly write into shared
buffers), so CPU doesn't need to act on each frame for each step
in the decoding pipeline ?
Playing an 800x400 mp4 still produces about 70..75%.
cu
--
Enrico Weigelt, metux
objects and
dma-bufs relate to each other ? Is it possible to directly exchange
buffers between GPUs, VPUs, IPUs, FBs, etc ?
cu
--
Enrico Weigelt, metux IT consult
+49-151-27565287
MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA
21333 B
Wichtiger Hinweis: Diese Nachricht kann ve
22 matches
Mail list logo
