When viewing an XBM x-bitmap image in Emacs, I noticed some help at the bottom status bar telling me I could use Ctrl-C, Ctrl-C to "view as text" so I did that and then the same sequence allows me to re-view it as image.

For me that was a very interesting cool discovery. Because I'm playing with some e-ink displays and one of the methods to place data on them is to create a full sized x-bitmap image file matching the display XY size, in gray scale, and then writing that image to the display. I was aware that had I used more or cat to view the file from the command line that it would show me a large data array, but in emacs it natively opens it as an image, much like you'd see in gimp. But that duality where you can view it in both modes is awesome because the program problems I face now are to make actively changing images, write different text and such and so I have to play with that data as part of my program logic.

I'm guessing others already knew this one, but it was still cool enough of a discovery for me today.

Create your own gray scale XBM file in gimp and give it a try.

Nice to know. I had to d/l and install both gimp and emacs to replicate but It's not like I had a whole lot else to do with snow and 15 degrees outside.

Might be better as an LQ blog entry. This thread will get buried in time.

Funny, I usually suggest that to people.

I guess I was being self-humble because it's not that great of a discovery. I'm creating a general emacs experience blog and will put this property into it. My thinking though is that the blog will cover a great deal of the total emacs experience from my perspective and this particular item will be there, but be later and very brief in comparison to the blog entry as a whole.

If you get around to blogging about writing to an e-ink display drop me a pm, I'd be interested in reading it.

Give this a whirl RePaper eInk Development Board for ARM + GNU/Linux, that is what I was playing with.

Couple of addendum's:

1. The AdaFruit stuff is "moderately" good, reality is always a tad bit different. They have customer forums where there are Q&A about each of their offerings and whether or not you find an actual answer, you do get some feedback from either other people or the developers
2. For this project Raspberry Pi was a complete non-starter, I could not even get the libraries to build, so I recommend you try BeagleBone Black
3. I iterated between BBB Rev C and Rev B. Rev B or earlier was used and they used Angstrom, whereas a Rev C BBB uses Debian. I got it to work for both. In Angstrom Rev B it works fine, for Debian Rev C it works; however there's an unintended horizontal screen line, indicating to me that there's one GPIO signal or more which needs to be resolved differently, but I do not know the solution yet there
4. Use whatever package management is available to get the packages installed that the guide tells you to do, when you build, the updated build (not-documented) requires the argument COG_VERSION then either =V1 or =V2 depending on the screen. BIG HOWEVER, they have a FAQ which very clearly tells you how to discern between V1 and V2 based on the bar codes on the screen part, and it's a year or more old, the newer labels appear nothing like what that FAQ says. I asked a question of the forum and got This Link. I had previously discovered that mine was V1 by trial and error, but this confirmation did help
5. A most important point was that the Python examples did not work, on the Rev B board you see all kinds of GPIO errors, but it works, and the main success I did have was in running the epd_test application. My issues were that I built as V2 first, tried the Python examples which don't work for either version, probably tried epd_test, but since I started trying V2 and saw all those GPIO errors I figured "fail". Well, by luck I did a do-over and rebuilt as V1 and then tried epd_test again, you still see the GPIO errors, at least in Rev B boards, it doesn't show up in Rev C/Debian; however the writing of the image files to the screen ended up working!
6. In both BBB cases, the epd_fuse driver did load and run, I think the Debian case had install complaints due to update-rc.d however it still did install it and loaded the driver at the next boot
7. Oh and there's a section where you can send ASCII single character commands to the panel to clear it or load an image, I tried that but the instructions were lacking and I'm unsure if it works at all, what I can say is the command to clear it does NOT work, so ... stick with epd_test and whatever that is doing I'm morphing that source to do what I want as part of my experimentations, it's all under the gratis/PlatformWithOS/driver-common directory, you build one layer up, and this is part of the documentation
8. It's a large amount of frustration, but in the end does work
9. Unsure where this will go, I'm taking this to some degree of proficiency so that I can be ready if we choose to use eink for the product; otherwise if we choose to stay with one of the LCD Capes, then we already have that coded and working with Qt
10. Another final note is the wiring for the BBB has one signal which it says "Not Yet" from the display to the BBB; I never hooked it up and it's working, I asked the forums about it and got zip, but it's very unclean where it tells you about one signal and then leaves an indeterminate "We're not going to yet tell you if you need that versus not." My suspicion is that this may have something to do with the extra lines I see for my Rev C board ...

1 members found this post helpful.

Thanks, a lot to digest. :-)

Yep, yet another future blog entry. Sad to say but I have like 4 "draft" blogs already.