looking for usb lcd - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: December 01, 2014, 02:16:36 am
content: hi guysi am looking for USB LCD that could be used as "linux frame buffer", i need something that is 480x272 or 800x480 pixel, 16:9 ratio, and … 5 inch sizedo you know something like that ?

author: Jeroen3
author_rank: Super Contributor
timestamp: December 01, 2014, 06:50:19 am
content: I've seen USB monitors. Nowadays they are probably USB 3.0, but it should work.Don't expect a high refresh rate.

author: legacy
author_rank: Super Contributor
timestamp: December 01, 2014, 12:48:39 pm
content: i can use only USB 2 high speed.Also, i need something in 5" (inch) size

author: dferyance
author_rank: Regular Contributor
timestamp: December 01, 2014, 02:50:03 pm
content: The closest I know of is the RoboPeak USB Display. It is smaller than your size requirements though. Otherwise you might have to come up with some kind of adapter. There are plenty of USB to SPI or parallel chips. Also the FBTFT driver is a good starting point.

author: Jeroen3
author_rank: Super Contributor
timestamp: December 01, 2014, 02:54:47 pm
content: It is linux, you can always write your own driver.

author: legacy
author_rank: Super Contributor
timestamp: December 01, 2014, 03:13:14 pm
content: Quote from: Jeroen3 on December 01, 2014, 02:54:47 pmthere is a practical difference between saying things and doing things, and linux makes this difference very very deepI am (unfortunately) involved into drivers, i can assure doing it is not so easy as saying you can do it

author: rob77
author_rank: Super Contributor
timestamp: December 01, 2014, 03:15:37 pm
content: what is the application ? have you considered reusing a tablet ? some android tablets have the drivers for linux available (e.g. allwinner A10).or is the USB a must ? then you could use the tablet as a display only - but that would require some low level coding (lot's of work).

author: Jeroen3
author_rank: Super Contributor
timestamp: December 01, 2014, 03:32:30 pm
content: Writing drivers isn't the same as hello world, I know.With the recent Raspberry Pi development you should not be the first one in need of a SPI or other LCD capable supported by some linux image driver.Example after googling "spi lcd linux"http://www.whence.com/rpi/

author: legacy
author_rank: Super Contributor
timestamp: December 01, 2014, 03:37:33 pm
content: it doesn't matter, they are SPI virtual frame buffer, i need USB defio frame buffer, theory are pretty different !BTW, my problem is to find the hardware, i need 5 inch 800x480x16bit LCD, USB driveni am evaluating ADA fruits products, in case i will try to adapt something with an MPU with a built in USB

author: free_electron
author_rank: Super Contributor
timestamp: December 01, 2014, 03:38:07 pm
content: Quote from: Jeroen3 on December 01, 2014, 02:54:47 pmi want to buy a bread.answer from the linux community : here is a field where you can grow your own wheat. here is some wood and tools so you can make a mill , there are some bricks to build an oven. meanwhile we will have a discussion about whole wheat versus plain white bread and if we should fire the oven with wood or gas...typical useless addition form the loonix world.

author: mrflibble
author_rank: Super Contributor
timestamp: December 01, 2014, 03:45:06 pm
content: I would look at something along the lines of running an X framebuffer on your favorite cheapo android tablet. Then either use usb transport directly, or my first attempt would be ethernet over usb. I've done almost all those components in the past and it works. Only ingredient I haven't done yet (no need so far) is the X framebuffer on android. Most of the work for that will be to compile a couple extra kernel modules for your tablet.For this particular solution you don't need to program anything new. Just compile something that already exists for a target that doesn't come with it installed by default.

author: mrflibble
author_rank: Super Contributor
timestamp: December 01, 2014, 04:15:35 pm
content: Quote from: legacy on December 01, 2014, 02:16:36 amTo avoid any confusion, can you give somewhat clearer requirements. What will be connecting to this usb lcd? As in, what will arranging the pretty pixels? A laptop running OS xyz? An MCU? Wut? Because I took you at your word that you really meant you wanted a linux frame buffer.And that then usually means <see previous solution>. But maybe your requirements are slightly different than your post leads us to believe.Do you really want something that you can treat as a framebuffer for some application that already runs on a working platform (whatever that is)? As in the usb attached display is "just" another remote display from the point of view of that OS xyz?

author: legacy
author_rank: Super Contributor
timestamp: December 01, 2014, 04:44:03 pm
content: Quote from: mrflibble on December 01, 2014, 04:15:35 pmmy request should be clear: i need a piece of hardware, an LCD of 5 inch (not bigger, not smaller), in 16:9 ratio, with 800x480x16 pixel, which is usb-driven as a virtual frame buffer, something the kernel is able to export as "/dev/fb0" (i am on an embedded linux board, there is no VIDEO card), i do not need any X11 or other strange things, just a frame buffer in order to support to my "directfb" applications.ADA fruit seems to have such an LCD, unfortunately its hardware driver is SPI driven: in case i need to adapt to USB, and then to write the kernel driver of the frame buffer. I have to decide what to do, looking around for other LCDs.

author: legacy
author_rank: Super Contributor
timestamp: December 01, 2014, 04:55:49 pm
content: p.s.do not associate "frame buffer" to "X11" !my first application was a "text console, fb driven", something linux is calling "fbcon" (which stands for "frame buffer console)fbcon is a kernel service, in my case i had no way to make fbcon to work (too complex to make it working in a SoC, i am not so good in kernel programming, and such a machine is not a common PC), so i coded a userspace application that works exactly like fbcon: it accesses /dev/fb0 in order to create a text console!easy and pretty piece of code, its perfect for my purposes, but i need an usb-lcd !

author: mrflibble
author_rank: Super Contributor
timestamp: December 01, 2014, 05:14:40 pm
content: I will associate frame buffer with whatever springs to mind as potential solution so long as it fits the requirements. ;-)There are several things your "frame buffer" could mean, and if you don't specify precisely what you need I'll just pick something I like based on past experience.So which is it? Your requirement is that you have to have a remote fbcon? In which case the "only" thing you need to do is set up arm toolchain for your target tablet, dump current config + build module for that kernel. No need for an entire kernel recompile, only the fbcon module + potential dependencies.Also, you didn't not specify what it is connected to. Or maybe you did but I misunderstood. You have your whatever it is that is displaying the pretty pixels. Noted. What device is connected to it over that usb connection? Is it a microcontroller? Is it a PC? Is it to be determined?Put another way:functionallywhat are you trying to do? And "usb-lcd framebuffer" is not an answer to that question. ;-)

author: mrflibble
author_rank: Super Contributor
timestamp: December 01, 2014, 05:50:18 pm
content: Quote from: legacy on December 01, 2014, 04:44:03 pmApologies, I am blind, and you did specify. And for this case the solution that works is indeed what I already suggested. You have the (relatively small) X display running on the remote tablet. Then you setup a tcp tunnel over usb, and point your application (on the embedded linux board) to the local socket. Traffic gets forwarded over tunnel to the remote display, and you have pretty pixels on the tablet.

author: free_electron
author_rank: Super Contributor
timestamp: December 01, 2014, 06:15:30 pm
content: why dont you use one of those usb video dongles. they export dvi and that is easy to hook up to an lcd.They are seen by the Os as a graphics card. here is one that work in linux :http://www.win-star.com/eshop/article.php?id=24

author: legacy
author_rank: Super Contributor
timestamp: December 01, 2014, 06:27:12 pm
content: Quote from: mrflibble on December 01, 2014, 05:14:40 pmNO! the fbcon is a kernel service that is not working on MIPS machine, it has been designed for PC, adapted to arm, but it does not work everywhere and it is a very long and complex piece of kernel source.Having a frame buffer service in kernel space makes you also able to have a device-name like "/dev/fb0", that is a good way to access the LCD video memory from the user space, which is excellent method to write your own "directfb" application!Quote from: mrflibble on December 01, 2014, 05:14:40 pmit'a custom application, too long story, i told you what i need: direct fb !Do you know "directfb" ? it is exactly what i am telling about, a way to directly handle a frame buffer, I have already written and tested these kind of things on other hardware (PC and embedded boards), so i am fine:my problem is related to find the hardware, and secondary to have a working USB_DEFIO_FB driver for such an hardware !Quote from: mrflibble on December 01, 2014, 05:14:40 pmWho has ever talked about ARM ? I am on a MIPS SoC machine, i have my pretty development toolchain: pretty fine with this kind of things, i usually recompile 3 times a day!Quote from: mrflibble on December 01, 2014, 05:14:40 pmfirst of all, fbcon does not work on MIPS machine, also it is not a module, it's a built-in service, so you MUST recompile the whole kernel which is not a problem for me. I do not want to have nothing to deal with fbcon, too complex, so i do not enable the fbcon, i have enabled the virtual frame buffer service and with the proper driver i will be quite fine in order to make the kernel to provide the userspace with /dev/fb0, which is perfect to create a text console from the userspace using direcfb!i have already coded, tested, and validated the directfb-text-console: it is working perfectly.Quote from: mrflibble on December 01, 2014, 05:14:40 pmLCD-USB----->USB-EHCI--MIPS-SoC-built-in-USBLCD----->URB_BULK-->kernel--->/dev/fb0--->userspace--->directfb--->my-applicationedit:i have found the LCD i am looking for, it's very expensive (120 Euro), but it's exactly what i need

author: Jeroen3
author_rank: Super Contributor
timestamp: December 01, 2014, 06:50:15 pm
content: Aren't you going to share details about the LCD?Otherwise it is such a disappointment for those who googled here.

author: legacy
author_rank: Super Contributor
timestamp: December 01, 2014, 06:59:29 pm
content: it's not a google product, it's a local product i had a confirm from the phone. Internal farm solution done aroundthisLCD interfaced to an MPU.The whole looks like an usb-bulk-driven frame buffer refreshed by a custom kernel module. The guy who has notified me this solution is working from an other customer i am following: so called collaboration, they have the LCD i am looking for, and they are looking for the application i have written. That's good!In the near future i want to analyze his firmware in order to understand what he has done an try to replicate his solution. As far as i understood he is using an arm-MPU to interface the LCD throughthishardware driver that is SPI driven, exporting everything to an USB-BULK-driven protocol.so the whole path will be something like this:LCD---parallel bus RGB+V+H---hw-driver--SPI---MPU---USB---BULK--------SoC's-built-in USB----kernel---/dev/fb0---directfb---application

author: mrflibble
author_rank: Super Contributor
timestamp: December 01, 2014, 07:01:21 pm
content: Yes I know directfb. Used it every once in a whilelocally, just not as remote display because that brings unnecessary challenges with it. At least it did at that point in time. I even have some super old directfb code floating around ... somewhere.Used the ramdac as a poor man's signal generator.QuoteYes, I got that. Hence the compile it (the module) yourself. And fbcon is not available as module? What kind of crazy talk is that?(not your crazy talk, the implementation I mean. Now you're just making me take a look at the code.) ... just checked it. FRAMEBUFFER_CONSOLE configuration type is a tristate, and you can specify it as module on i368 (yes, not checking MIPS).Would have been rather curious if it hadn't.But it notworkingon MIPS is new for me. Thanks for the info. Do you happen to have a link related to why it's not working on MIPS? Just so ... odd. Anyways the miscommunication is because 99% of people that say "but it's not working" really mean "but I don't know how to compile a module on tricky target platform". And I mistakenly put you into that category. My bad.And I see your problem has been solved, so it's all a moot point.