2013-06-25 41 views
5

Thiết bị của tôi là Nexus 4 chạy Jelly Bean 4.2. Tôi đang cố gắng ghi lại màn hình và gửi nó đi. Hầu hết các mã trên internet thực hiện việc đọc bằng cách đọc/dev/graphics/fb0. Nó hoạt động tốt trong một số thiết bị và các hệ thống cũ hơn. Nhưng khi tôi thử nó trên thiết bị của tôi, nó không thành công. Nó chỉ cho tôi màn hình đen và tất cả "0" trong dữ liệu thô. Tôi đã chạy "adb root" để có quyền root, thử "chmod 777 fb0", "cat fb0>/sdcard/fb0". Ngoài ra tôi đã thử các mã như "mmap" và "memcpy" để lấy dữ liệu. Nhưng tất cả đều thất bại. Tôi đã tìm kiếm trên internet và dường như không có giải pháp. Và một số chủ đề nói rằng hạt nhân có thể cấm bạn đọc fb0. Bất cứ ai có ý tưởng về điều đó?Đọc Android fb0 luôn cho tôi màn hình màu đen

+1

Với GPU hiện đại hơn, framebuffer có lẽ chỉ không trivially truy cập (ít nhất là không trọn vẹn) để CPU chính hầu hết thời gian. Hầu hết các triển khai của ADBD từ lâu đã được chuyển sang sử dụng một tệp thực thi độc nhất thiết bị bên ngoài được gọi là một cái gì đó giống như screencap để thực hiện công việc thực tế của việc thu thập bộ đệm khung (framebuffer). Bạn có thể sử dụng nó, cố gắng tìm tài liệu/nguồn hoặc cố gắng thiết kế ngược lại tệp thực thi. Thông thường tôi muốn nói "may mắn" trên nguồn, nhưng đối với một thiết bị Nexus nó thực sự có thể có sẵn (hoặc họ chỉ có thể cung cấp các nhị phân cùng với các bit đóng khác) –

+1

Cảm ơn bạn đã trả lời. Trên thực tế, mã gốc của Android chứa hai tên thực thi: screencap và ảnh chụp màn hình. Và có hai cách trong mã của họ. Một là bằng cách đọc fb0, khác là bằng cách gọi glPixel() được cung cấp bởi thư viện gốc của Android. Cái thứ hai khá chậm. Trên thực tế tôi đã thực hiện một với phương pháp thứ hai, nhưng khung hình/giây không phải là lý tưởng. Vì vậy, tôi quay trở lại và cố gắng làm điều đó theo cách đầu tiên. Không có hạn chế trong dự án của tôi. Tôi thậm chí có thể hack hạt nhân để thực hiện nó. Bị mắc kẹt bởi vấn đề trong nhiều tuần. Cần giúp đỡ. – user1659072

+0

Những gì bạn cần là thông tin lập trình GPU cấp thấp, đáng buồn thay, thường không được các nhà sản xuất phát hành. Tôi không tin rằng họ đã từ bỏ việc fb đơn giản được đọc là khó khăn hoặc thậm chí cho an ninh; họ đã làm điều đó bởi vì phần cứng không còn dễ dàng (hoặc ít nhất là portably) tiếp xúc với toàn bộ điều như một bộ đệm tiếp giáp.Tôi đã thực hiện một thay đổi khác ngay sau lần thay đổi này để đọc framebuffer thực trong các đoạn tương tác với một số mã mức thấp - hiệu quả hơn pixel theo pixel, nhưng lại độc đáo với phần cứng cụ thể. –

Trả lời

5

Khi tiến bộ phần cứng, bạn càng ít có khả năng tìm thấy một bộ đệm khung thực sự với nội dung màn hình trong đó.

Như đã lưu ý trong các chú thích, adb sử dụng lệnh "screencap", liên hệ với trình xử lý bề mặt thông qua một cuộc gọi Binder, rơi trở lại /dev/graphcs/fb0 nếu điều đó không thành công. Con đường thứ hai hiếm khi được sử dụng bây giờ.

Nếu bạn thực sự muốn tìm hiểu cách hoạt động của tính năng này, bạn cần kiểm tra cách bố cục bề mặt làm thành phần, đặc biệt là HAL. Các nhà soạn nhạc phần cứng mất nhiều bề mặt gralloc và composites chúng trong quá trình quét ra. Cách hoạt động này khác với thiết bị; việc thực hiện hwcomposer thường được thực hiện bởi nhà sản xuất chip đồ họa.

Tạo màn hình, được sử dụng bởi khung ứng dụng để tạo hình thu nhỏ cho tính năng "ứng dụng gần đây", áp dụng các bước thành phần tương tự HWC nhưng độc quyền với GLES. Kể từ Android 4.2, nhà soạn nhạc phần cứng không thể kết hợp thành bộ đệm.

Đôi khi nhà soạn nhạc phần cứng "punt", ví dụ: bởi vì có nhiều lớp để tổng hợp hơn so với phần cứng có thể xử lý. Trong trường hợp đó, trình sửa bề mặt sẽ chuyển thành thành phần GLES và sẽ có bộ đệm ở đâu đó có hình ảnh hoàn chỉnh; dù bạn có tìm thấy nó hay không bằng cách mở /dev/graphics/fb0 là một vấn đề khác.

Một số điểm bắt đầu:

Các vấn đề liên quan