Sure.
I will make it a bit later, when I have the more stable result.
Best regards,
Alexander
>Понедельник, 20 апреля 2020, 8:59 +03:00 от Oleksandr Andrushchenko
>:
>
>Hi,
>
>On 4/19/20 14:26, Santucco wrote:
>> Hello,
>> I have found a source of the problem.
>> In displ_be, BaseDump
Hi,
On 4/19/20 14:26, Santucco wrote:
> Hello,
> I have found a source of the problem.
> In displ_be, BaseDump copies to the drm buffer with a size from
> i915 drm driver, but this size a bit more than a size of my frontend
> display buffer. I have made a quick and dirty fix, a copy a line of
Ok, thank you very much.
One more question - is that normal the /dev/drm/card0 device is mapped at
offset more then 4Gb?
Best regards,
Alexander
>Четверг, 6 февраля 2020, 11:20 +03:00 от Oleksandr Andrushchenko
>:
>
>On 2/5/20 8:59 PM, Santucco wrote:
>> Hello,
>> Ok, I commented out the
On 2/5/20 8:59 PM, Santucco wrote:
> Hello,
> Ok, I commented out the memcpy call and run the test.
> displ_be hasn’t crached, I have seen FLIP events in the log.
> But there hasn’t been the black screen, just a blink effect every
> couple of seconds.
> Logs are attached.
Ok, so I believe that
On 2/4/20 10:28 AM, Santucco wrote:
> Hello,
> displ_be was compiled without zero-copy support early.
> I have tried with the recompiled dom0 kernel, a result is the same.
> Logs and configs (+displ_be’s CMakeCache.txt ) are attached.
Ok, yet another test to localize the problem.
Could you please
Hello,
displ_be was compiled without zero-copy support early.
I have tried with the recompiled dom0 kernel, a result is the same.
Logs and configs (+displ_be’s CMakeCache.txt ) are attached.
Best regards,
Alexander
>Понедельник, 3 февраля 2020, 10:36 +03:00 от Oleksandr Andrushchenko
On 2/1/20 4:39 PM, Santucco wrote:
> Hello again,
> I have not yet made to work my drm client, so I have tried to run
> linux like a domU (to see how it should work), it doesn’t work too
> — displ_be catches SIGSEGV:
>
> #0 0x7f4afed1c161 in ?? () from /lib64/libc.so.6
> #1
Hello again,
I have not yet made to work my drm client, so I have tried to run linux like a
domU (to see how it should work), it doesn’t work too — displ_be catches
SIGSEGV:
#0 0x7f4afed1c161 in ?? () from /lib64/libc.so.6
#1 0x55723b9c5bec in Drm::DumbDrm::copy
On 1/8/20 5:38 PM, Santucco wrote:
> Thank you very much for all your answers.
>
> Среда, 8 января 2020, 10:54 +03:00 от Oleksandr Andrushchenko
> >:
> On 1/6/20 10:38 AM, Jürgen Groß wrote:
> > On 06.01.20 08:56, Santucco wrote:
> >> Hello,
> >>
> >> I’m trying
Thank you very much for all your answers.
>Среда, 8 января 2020, 10:54 +03:00 от Oleksandr Andrushchenko <
>oleksandr_andrushche...@epam.com >:
>
>On 1/6/20 10:38 AM, Jürgen Groß wrote:
>> On 06.01.20 08:56, Santucco wrote:
>>> Hello,
>>>
>>> I’m trying to use vdispl interface from PV OS, it
On 1/6/20 10:38 AM, Jürgen Groß wrote:
> On 06.01.20 08:56, Santucco wrote:
>> Hello,
>>
>> I’m trying to use vdispl interface from PV OS, it doesn’t work.
>> Configuration details:
>> Xen 4.12.1
>> Dom0: Linux 4.20.17-gentoo #13 SMP Sat Dec 28 11:12:24 MSK 2019
>> x86_64 Intel(R)
On 06.01.20 08:56, Santucco wrote:
Hello,
I’m trying to use vdispl interface from PV OS, it doesn’t work.
Configuration details:
Xen 4.12.1
Dom0: Linux 4.20.17-gentoo #13 SMP Sat Dec 28 11:12:24 MSK 2019 x86_64
Intel(R) Celeron(R) CPU N3050 @ 1.60GHz GenuineIntel GNU/Linux
DomU:
Hello,
I’m trying to use vdispl interface from PV OS, it doesn’t work.
Configuration details:
Xen 4.12.1
Dom0: Linux 4.20.17-gentoo #13 SMP Sat Dec 28 11:12:24 MSK 2019 x86_64
Intel(R) Celeron(R) CPU N3050 @ 1.60GHz GenuineIntel GNU/Linux
DomU: x86 Plan9, PV
displ_be as a backend
13 matches
Mail list logo
