| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Change-Id: Ibd2f67391ce6d7774498839829e0de9391508781
|
| |
|
|
|
|
|
| |
This type of vibrator is found on newer kernel versions (4.9+) and
registers with LED class framework (located at /sys/class/leds/vibrator).
Change-Id: I85e93fdac17b3f4b6f2ae689bbbd490806b5c29b
|
| |
|
|
|
|
| |
Fix conflicts and make it build in 5.1, 6.0, 7.1, 8.1, and 9.0
Change-Id: Ida0a64c29ff27d339b7f42a18d820930964ac6e4
|
| |
|
|
| |
Change-Id: Iaebc613a25a727a91205d2f361e9d7719036d88d
|
| |
|
|
|
|
|
|
| |
Includes some minor code clean up. Also we are now outputting the
name of the first mouse device that we encounter to make it easier
to identify which device(s) may need to be blacklisted.
Change-Id: I515baf92967390edd224728f3a7092239138e6b8
|
|
|
Note: events.cpp is still old code renamed to cpp to make it
easier to call functions like gr_fb_width().
I had to modify AOSP fbdev code to provide a separate memory
surface for drawing to as drawing directly to the framebuffer
resulted in rendering taking about 5 times longer.
I also modified AOSP adf code to provide a separate memory surface
for drawing for the same performance reasons. The Nexus 9 supports
adf graphics.
Overlay graphics work on at least one device. Overlay provides a
separate memory buffer already so performance is good.
I do not have a drm device yet that I know of. I made some attempt
to update the drm code to determine the correct pixel format based
on the drm graphics format, but what is available in pixel flinger
and what is available in drm do not line up all that well. Reports
are that the Pixel C is using drm graphics, but performance is
slow, likely due to the use of a mmap instead of a memory buffyer.
Change-Id: Ibd45bccca6ac2cb826037aa9b2aa5065cf683eed
|
