On 10 October 2013 14:37, Dmitrijs Ledkovs <email address hidden> wrote:
> On 10 October 2013 14:15, Colin King <email address hidden> wrote:
>> I believe the library /vendor/lib/hw/hwcomposer.omap4.so depends on
>> these VSYNCs, I'm unsure how the plumbing works between the kernel and
>> this library - is this proprietary code?
>>
>> The kernel just shoves these VSYNC uevents outs for the
>> hwcompiser.omap4.so to handle. I am of the current understanding that it
>> is not used by anything else.
>>
>
> Proprietary or not it's source code is here:
>
> https://android.googlesource.com/platform/hardware/ti/omap4-aah/+/master/hwc/hwc.c
>
> Or at least appears to be and/or similarish.
so if we filter those VSYNC events on the "udev" source, systemd-udev
& upstart & et al user space shouldn't be spammed with those and the
driver will still work.
On 10 October 2013 14:37, Dmitrijs Ledkovs <email address hidden> wrote: lib/hw/ hwcomposer. omap4.so depends on /android. googlesource. com/platform/ hardware/ ti/omap4- aah/+/master/ hwc/hwc. c
> On 10 October 2013 14:15, Colin King <email address hidden> wrote:
>> I believe the library /vendor/
>> these VSYNCs, I'm unsure how the plumbing works between the kernel and
>> this library - is this proprietary code?
>>
>> The kernel just shoves these VSYNC uevents outs for the
>> hwcompiser.omap4.so to handle. I am of the current understanding that it
>> is not used by anything else.
>>
>
> Proprietary or not it's source code is here:
>
> https:/
>
> Or at least appears to be and/or similarish.
Which appears to be getting a FD to "kernel" event source, via socket created by /android. googlesource. com/platform/ hardware/ libhardware_ legacy/ +/android- 4.3_r3/ uevent/ uevent. c
https:/
so if we filter those VSYNC events on the "udev" source, systemd-udev
& upstart & et al user space shouldn't be spammed with those and the
driver will still work.
Regards,
Dmitrijs.