- Có vẻ như không có quá nhiều tùy chọn để lập trình với fb từ không gian người dùng trên máy tính để bàn ngoài những gì bạn đã đề cập. Đây có thể là một lý do tại sao một số tài liệu quá cũ. Hãy xem tài liệu này cho nhà văn trình điều khiển thiết bị và được tham chiếu từ một số tài liệu chính thức của Linux: www.linux-fbdev.org [dấu gạch chéo] HOWTO [dấu gạch chéo] index.html. Nó không tham chiếu quá nhiều giao diện .. mặc dù nhìn vào cây mã nguồn Linux cung cấp các ví dụ mã lớn hơn.
- opentom.org [dấu gạch chéo] Hardware_Framebuffer không dành cho môi trường máy tính để bàn. Nó củng cố phương pháp luận chính, nhưng nó dường như tránh giải thích tất cả các thành phần cần thiết để thực hiện chuyển đổi bộ đệm đôi "nhanh" mà nó đề cập đến. Một cái khác cho một thiết bị khác và để lại một số chi tiết đệm chính là wiki.gp2x.org [slash] wiki [slash] Viết_to_the_framebuffer_device, mặc dù ít nhất nó cũng gợi ý bạn có thể sử dụng fb1 và fb0 để tham gia đệm đôi (trên cái này thiết bị .. mặc dù cho máy tính để bàn, fb1 có thể không khả thi hoặc có thể truy cập phần cứng khác), sử dụng từ khóa dễ bay hơi có thể thích hợp và chúng ta nên chú ý đến vsync.
- asm.sourceforge.net [slash] bài viết [slash] fb.html thói quen ngôn ngữ lắp ráp cũng xuất hiện (?) Để làm những điều cơ bản về truy vấn, mở, thiết lập một số khái niệm cơ bản, mmap, vẽ các giá trị pixel để lưu trữ và sao chép sang bộ nhớ fb (đảm bảo sử dụng vòng lặp stosb ngắn, tôi cho rằng, thay vì một số cách tiếp cận dài hơn).
- Cảnh giác với 16 bpp nhận xét khi googling đệm khung Linux: Tôi đã sử dụng fbgrab và fb2png trong phiên X không có kết quả. Những hình ảnh này đưa ra một hình ảnh gợi ý ảnh chụp màn hình máy tính để bàn của tôi như thể hình ảnh của máy tính để bàn đã được chụp bằng máy ảnh rất xấu, dưới nước và sau đó bị phơi sáng quá mức trong một căn phòng tối. Hình ảnh đã bị hỏng hoàn toàn về màu sắc, kích thước và thiếu nhiều chi tiết (rải rác trên tất cả các màu pixel không thuộc về). Có vẻ như/proc/sys trên máy tính tôi đã sử dụng (hạt nhân mới có ít sửa đổi nhất .. từ một dẫn xuất PCLOS) cho rằng fb0 sử dụng 16 bpp, và hầu hết mọi thứ tôi googled đã nói điều gì đó dọc theo những dòng đó, nhưng các thử nghiệm dẫn tôi đến một kết luận rất khác.Bên cạnh kết quả của hai lỗi này từ các tiện ích lấy bộ đệm khung tiêu chuẩn (đối với các phiên bản được tổ chức bởi bản phân phối này) có thể đã giả định 16 bit, tôi đã có kết quả kiểm tra thành công khác khi xử lý dữ liệu pixel đệm khung là 32 bit. Tôi đã tạo một tệp từ dữ liệu được lấy qua cat/dev/fb0. Kích thước của tập tin đã kết thúc là 1920000. Sau đó tôi đã viết một chương trình C nhỏ để thử và thao tác dữ liệu đó (theo giả định nó là dữ liệu pixel trong một số mã hóa hoặc khác). Tôi đóng đinh nó cuối cùng, và các định dạng pixel phù hợp chính xác những gì tôi đã nhận được từ X khi truy vấn (TrueColor RGB 8 bit, không có alpha nhưng đệm đến 32 bit). Chú ý một đầu mối khác: độ phân giải màn hình của tôi là 800x600 lần 4 byte cho 1920000 chính xác. Các phương pháp tiếp cận 16 bit tôi đã thử ban đầu tất cả đã tạo ra một hình ảnh bị hỏng tương tự như fbgrap, vì vậy nó không giống như tôi có thể không nhìn vào dữ liệu đúng. [Hãy cho tôi biết nếu bạn muốn mã tôi sử dụng để kiểm tra dữ liệu. Về cơ bản tôi chỉ đọc trong toàn bộ fb0 dump và sau đó nhổ nó ra tệp, sau khi thêm tiêu đề "P6 \ n800 600 \ n255 \ n" để tạo tệp ppm phù hợp và trong khi lặp qua tất cả các pixel thao tác theo thứ tự hoặc mở rộng chúng, .. với kết quả thành công cuối cùng cho tôi là để thả mỗi byte thứ 4 và chuyển đổi đầu tiên và thứ ba trong mỗi đơn vị 4 byte. Trong ngắn hạn, tôi biến BGRA fb0 xuất hiện thành một tệp ppm RGB. ppm có thể được xem với nhiều người xem pic trên Linux.]
- Bạn có thể xem xét lại lý do muốn lập trình sử dụng fb0 (điều này cũng có thể giải thích lý do tại sao có ít ví dụ). Bạn có thể không đạt được bất kỳ lợi ích hiệu suất đáng giá nào so với X (đây là của tôi, nếu có giới hạn, kinh nghiệm) trong khi từ bỏ lợi ích của việc sử dụng X. Lý do này cũng có thể giải thích tại sao một số ví dụ mã tồn tại.
- Lưu ý rằng DirectFB không phải là fb. DirectFB đã nhận được nhiều tình yêu hơn so với fb cũ, vì nó tập trung nhiều hơn vào việc tăng tốc 3D hw. Nếu bạn muốn hiển thị trên màn hình desktop nhanh nhất có thể mà không tận dụng tăng tốc phần cứng 3d (hoặc thậm chí tăng tốc 2d), thì fb có thể tốt nhưng sẽ không cho bạn nhiều thứ mà X không cung cấp cho bạn. X dường như sử dụng fb, và chi phí có thể không đáng kể so với các chi phí khác mà chương trình của bạn có thể có (không gọi X trong bất kỳ vòng lặp chặt chẽ nào, nhưng thay vào đó khi bạn đã thiết lập tất cả các pixel cho khung). Mặt khác, nó có thể gọn gàng để chơi xung quanh với fb như được đề cập trong nhận xét này: Paint Pixels to Screen via Linux FrameBuffer
Đó là một chút chung chung, bạn có thể cho tôi hướng cụ thể hơn không? – NoMoreZealots