| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Let vendor choose which framebuffer ioctl (FBIOPUT_VSCREENINFO or
FBIOPAN_DISPLAY) is best suited to do page-flip on its target platform.
Neither API is well documented about their usage and most of the
time it really depends on the respective framebuffer driver implementation.
* Default ioctl to do page-flip is FBIOPUT_VSCREENINFO.
* Set "TARGET_USE_PAN_DISPLAY=true" in board config file to use FBIOPAN_DISPLAY.
Change-Id: Ic3a50bd0f5fe37ac0149e11649c4abdadea85529
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| | |
Not every 32bpp is in RGBX format.
Change-Id: Ic3c6a0cbf475bff2fe2fc4b023c6bc58e4fc295e
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
private_handle_t's memory layout must be consistent between the 32-bit
and 64-bit gralloc, in case buffers are passed between processes.
Replace the (variably sized) uintptr_t base with a fixed size uint64_t,
and enforce 8-byte alignment for architectures where uint64_t alignment
varies between 32-bit and 64-bit.
Change-Id: I06cb31d4b9620ea18e5b50d3a3142b5adb2d2a14
Signed-off-by: Greg Hackmann <ghackmann@google.com>
|
|/
|
|
| |
Change-Id: I7cf9d04828f19b8d7d1d3b8948bef580b101b10c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A constant sNumInts with a value of 6 was being assigned to the numInts
attribute in the private_handle_t constructor, and was also used in the
validate method. That constant value is appropriate for 32-bit systems
but is not appropriate for a 64-bit system where uintptr_t used for
base attribute will be 64-bit.
sNumInts is now changed to a static inline function that calculates
numInts.
Change-Id: I482ddb5915c9ff55fb2e2a87887a0ec2dc2299ed
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
|
|
|
|
|
|
|
| |
Fix LP64 pointer casting warnings, unused parameters, and
turn off missing initializer warnings.
Change-Id: Idb70f4534282fed64ae81cb1e154d3f5b93091b0
|
|
|
|
|
|
|
| |
LOCAL_MODULE_PATH doesn't work for multiarch builds, replace it
with LOCAL_MODULE_RELATIVE_PATH.
Change-Id: I4e4ceec61d026bbe74ba604554c06104bde42e5e
|
|
|
|
| |
Change-Id: Ibc7e70887b61f7dd885c86d412387636d3a6a867
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I196ee30ed57707ed4cc46fb3a9c5c07c5bac6fff
|
|/
|
|
|
|
| |
Avoiding the use of gnu extensions improves code portability
Change-Id: Icf8e3d4813bcddff40548bb5e65e615f8697b75c
|
|
|
|
|
| |
Bug: 8468756
Change-Id: Ia883f459ea9e2648ca4a0b5a6f09ded4f46f13b3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The register/unregister gralloc calls were avoiding
mmapping/munmapping the shared memory region if the buffer was created
by the current process. This is left over from the pmem-based
implementation, where trying to map the same region twice in the same
process would fail, or would reuse a single mapping without
refcounting.
This causes problems if a buffer is
- allocated in process A,
- transferred from A to process B and registered there
- unregistered/freed in A
- transferred back from B to A and re-registered
Process A then has a new handle to the buffer, but since it originally
created the buffer it will not be mmapped, so trying to read or write
the buffer will crash.
With ashmem, mmaping a region twice in the same process creates two
distinct mappings which can be used and munmapped independently. So
we no longer need to avoid mmapping again in the allocating process.
Bug: 8468756
Change-Id: I167bec5ca07e5534c5e2115630fe8386e481388e
|
|\
| |
| |
| |
| |
| |
| | |
in fb_device_open()"
* commit '8405fe5a5203af18f39fd47b35606f0b32cd956c':
remove seemed useless gralloc_open() call in fb_device_open()
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
fb_device_open()"
* commit '1fbbb08ddda4321ccdb05345658044c1f0235997':
remove seemed useless gralloc_open() call in fb_device_open()
|
| | |
| | |
| | |
| | |
| | | |
Change-Id: I520e460bd558934c71042b5a4fdb03b3935ad720
Signed-off-by: suyi Yuan <yuan.suyi@gmail.com>
|
|/ /
| |
| |
| | |
Change-Id: I0621bd70896385c3d522d283a1be714f5f29df3b
|
| |
| |
| |
| |
| |
| |
| | |
See https://android-git.corp.google.com/g/#/c/157220
Bug: 5449033
Change-Id: I0cbe865d464a37365fa3be84948b07e5a0d181d0
|
| |
| |
| |
| |
| |
| |
| | |
See https://android-git.corp.google.com/g/157065
Bug: 5449033
Change-Id: I135fadaf10e95af1eb918889a22980c194c650ca
|
| |
| |
| |
| |
| |
| |
| | |
See https://android-git.corp.google.com/g/156801
Bug: 5449033
Change-Id: Ia8b6f74b27098b3dba27f177a76264eb23f849ee
|
|/
|
|
|
|
|
| |
See https://android-git.corp.google.com/g/156016
Bug: 5449033
Change-Id: I98e83cc9d22f0ea8fbf397ccccd9ce7773119551
|
|
|
|
| |
Change-Id: Ideadd5f39693d05cf29a81d9f87ed804d7e52380
|
|\
| |
| |
| |
| |
| |
| | |
problems
* commit 'cb4ea7ac8af7ac0732f480dc4938e62566bd5550':
Allow to force 16bpp when 32bpp has problems
|
| |
| |
| |
| |
| |
| | |
Bug: 4197654
Change-Id: Icf1e8793d6a4d2e070a8f232efd4136d79339496
|
|/
|
|
|
| |
Change-Id: I8a0ba7e4c99e334b9789d88b48383439eb7cc780
Signed-off-by: Iliyan Malchev <malchev@google.com>
|
|
|
|
|
|
|
| |
Note: The code under hardware/libhardware/modules/gralloc/ is only used
when running the system under the emulator.
Change-Id: I022978aeaacc5137c9917cd2ef6952dd3897ece4
|
|
|
|
|
|
|
|
| |
This patch avoids a division-by-0 when the system is running
under emulation (the kernel driver reports pixclock as 0, for
some reason). Which results in a SIGFPE during the boot sequence.
Change-Id: Idb6bcdd58999ea9231f2411481c25929d5d02f1d
|
|
|
|
|
|
|
|
|
|
| |
Some devices have low-level bugs in their page-flip.
Disabling it at this level gives us more flexibility
than trying to control it elsewhere.
Bug: 3097357
Change-Id: Icc6ae172264e453bec0680e74a497a2b24299c4a
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
this gralloc module is only used on the emulator or without a h/w
renderer. therefore there is no synchronization to do in lock/unlock
and pmem buffers are not relevant.
hopefully this will remove some of the confusion about how gralloc
should be implemented and make it more obvious that this implementation
is not intended to be used by h/w renderers.
|
|
|
|
|
| |
This fail to compile without NDEBUG and the following log statement does
something similar.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
we now automatically size the pmem region isntead of using hardcoded values
|
|
|
|
| |
specific ioctl.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
in Éclair build ERC07,rebooted automatically
|
| |
|
|\
| |
| |
| |
| | |
* changes:
Fix build on some linux distros.
|
| |
| |
| |
| |
| |
| |
| | |
The place where the PAGE_SIZE value is defined varies, mostly because
you're not supposed to be using it directly. sysconf(_SC_PAGE_SIZE)
is the approved method, and in fact some Linux distros actually #define
PAGE_SIZE to the library call.
|