sainsmart 7in lcd touch screen no display quotation

Notices: The capability of SD card in used here should be more than 4GB. In this operation, a SD card reader is also required, which has to be purchased separately.

An exclusive Complete Kit from SainSmart that includes the latest edition of the Raspberry Pi family - The Raspberry Pi 3 Model B and everything you need to get up and running within minutes in the exciting world of Raspberry Pi!

The enclosure is made out of a tough ROHS certified material providing easy access to power, audio/video, USB, LAN, microSD, DSI display adaptor and camera connector. It features feet and vents to ensure the board gets proper cooling, and plus-shaped wall mounting slots. This is a really slick case and once you"ve gotten your hands on a Raspberry Pi B+ , you"ll want to snag one of these to put it in!

The Raspberry Pi 3 has an identical form factor to the previous Pi 2 (and Pi 1 Model B+) and has complete compatibilitywithRaspberry Pi 1 and 2.Note:All the existing Raspberry Pi 2 accessories and kitsare fully compatible with the Raspberry Pi 3.

In the previous article, I described the steps needed to install an LCD touchscreen on the Raspberry Pi. In this article, I will show you how to adjust the screen rotation of the LCD to landscape mode, and will show you how to calibrate the touchscreen pointer for optimal accuracy. Just follow the steps below to compete the process of setting up your Raspberry Pi LCD touchscreen:

1. First we need to change the setting for screen rotation in the /boot/cmdline.txt file. This setting is called fbtft_device.rotate=X. By default, this is set to X=0, which results in a portrait mode screen orientation. In order to switch the orientation to landscape mode, change fbtft_device.rotate=0 to fbtft_device.rotate=90. Enter sudo nano /boot/cmdline.txt at the command prompt. There should only be one line in this file. Go to the end of it and you will find the fbtft_device.rotate=X setting. Change the value from 0 to 90:

However, if you try to touch the screen now, you will find that the pointer movement does not correspond to your finger movement. This is because the LCD screen driver and the touchscreen controller driver have separate settings for screen rotation. We need to change the rotation of the touchscreen controller driver to match the rotation of the LCD screen driver.

2. You probably noticed that dragging your finger to the right moves the pointer up, not to the right. This indicates that the x and y axes of the touchscreen are swapped. To correct this, we need to swap the x axis for the y axis. This can be done by changing the swap_xy=X parameter in /etc/modules.

Enter sudo nano /etc/modules at the command prompt to edit the file. Go to the line for the ads7846_device parameters and move the cursor to the right to find it:

Now if you drag your finger around the screen, you will notice that the y axis (up and down) is correctly aligned with the motion of your finger. However, the x axis (left and right) is still inverted. To fix this, we need to install two more kernel modules, xinput and evtest. xinput is a Linux utility that will allow us to configure input device settings for the touchscreen controller, and evtest is an input device event monitor and query tool.

After the Pi finishes rebooting, you should notice that when you move your finger across the touch screen, the pointer should follow correctly in both axes. If you are using the Raspberry Pi 2 Model B, you will need to complete the calibration steps below before the pointer follows your finger correctly (and make sure that you have enabled startx to load automatically – see step 6 in this article).

You can rotate the screen 90 degrees (as we did in this tutorial) and the power connector will be at the bottom of the screen, but you can also rotate it 270 degrees so that the power connector is at the top of the screen. To do this, simply enter fbtft_device.rotate=270 in the /boot/cmdline.txt file. Then change the DISPLAY=:0 xinput --set-prop "ADS7846 Touchscreen" "Evdev Axis Inversion" 0 1 line in the /etc/X11/xinit/xinitrc file to DISPLAY=:0 xinput --set-prop "ADS7846 Touchscreen" "Evdev Axis Inversion" 1 0. All you need to do is switch the values of the 0 and 1 at the end of this line.

Now that we have our LCD touchscreen up and running, the final step in the installation is the calibration of touch control. This will make the pointer much more accurate and easier to use.

2. Now we need to install the calibration tool we will be using, xinput_calibrator; and other filters for controlling the touchscreen response. Install the tslib library by entering aptitude install libts-bin:

4. Now we can use ts_calibrate. Enter ts_calibrate at the command prompt (make sure you are still in root mode) to run the ts_calibrate program. The program will consecutively display five crosses on different parts of the screen, which you need to touch with as much precision as possible:

Drag the cross around the screen and observe how closely it follows your finger or stylus to test the accuracy of the calibration. Now press the “Draw” button to enter the drawing mode:

This is kind of a long process, but it is well worth it if you want to get the LCD touchscreen set up properly. So if you have any trouble setting this up or have anything to say, please leave a comment below. Also, if you found this article useful, please share it with your friends!

Is there a way that I can make images that are read off of a SD card load faster? My code is below. This is not the complete code but enough to load a boot logo then a single screen.

While not on Android OS, I"d like to share my experience on getting it running a minimal debian/raspbian based Linux distro - Minibian https://minibianpi.wordpress.com/download/.

during this time,assuming the module is correctly connected to the Pi, the display should be completely white. this is a good sign that the device is atleast getting the power

In this Arduino touch screen tutorial we will learn how to use TFT LCD Touch Screen with Arduino. You can watch the following video or read the written tutorial below.

For this tutorial I composed three examples. The first example is distance measurement using ultrasonic sensor. The output from the sensor, or the distance is printed on the screen and using the touch screen we can select the units, either centimeters or inches.

The next example is controlling an RGB LED using these three RGB sliders. For example if we start to slide the blue slider, the LED will light up in blue and increase the light as we would go to the maximum value. So the sliders can move from 0 to 255 and with their combination we can set any color to the RGB LED,  but just keep in mind that the LED cannot represent the colors that much accurate.

The third example is a game. Actually it’s a replica of the popular Flappy Bird game for smartphones. We can play the game using the push button or even using the touch screen itself.

As an example I am using a 3.2” TFT Touch Screen in a combination with a TFT LCD Arduino Mega Shield. We need a shield because the TFT Touch screen works at 3.3V and the Arduino Mega outputs are 5 V. For the first example I have the HC-SR04 ultrasonic sensor, then for the second example an RGB LED with three resistors and a push button for the game example. Also I had to make a custom made pin header like this, by soldering pin headers and bend on of them so I could insert them in between the Arduino Board and the TFT Shield.

Here’s the circuit schematic. We will use the GND pin, the digital pins from 8 to 13, as well as the pin number 14. As the 5V pins are already used by the TFT Screen I will use the pin number 13 as VCC, by setting it right away high in the setup section of code.

I will use the UTFT and URTouch libraries made by Henning Karlsen. Here I would like to say thanks to him for the incredible work he has done. The libraries enable really easy use of the TFT Screens, and they work with many different TFT screens sizes, shields and controllers. You can download these libraries from his website, RinkyDinkElectronics.com and also find a lot of demo examples and detailed documentation of how to use them.

After we include the libraries we need to create UTFT and URTouch objects. The parameters of these objects depends on the model of the TFT Screen and Shield and these details can be also found in the documentation of the libraries.

Next we need to define the fonts that are coming with the libraries and also define some variables needed for the program. In the setup section we need to initiate the screen and the touch, define the pin modes for the connected sensor, the led and the button, and initially call the drawHomeSreen() custom function, which will draw the home screen of the program.

So now I will explain how we can make the home screen of the program. With the setBackColor() function we need to set the background color of the text, black one in our case. Then we need to set the color to white, set the big font and using the print() function, we will print the string “Arduino TFT Tutorial” at the center of the screen and 10 pixels  down the Y – Axis of the screen. Next we will set the color to red and draw the red line below the text. After that we need to set the color back to white, and print the two other strings, “by HowToMechatronics.com” using the small font and “Select Example” using the big font.

Next is the distance sensor button. First we need to set the color and then using the fillRoundRect() function we will draw the rounded rectangle. Then we will set the color back to white and using the drawRoundRect() function we will draw another rounded rectangle on top of the previous one, but this one will be without a fill so the overall appearance of the button looks like it has a frame. On top of the button we will print the text using the big font and the same background color as the fill of the button. The same procedure goes for the two other buttons.

Now we need to make the buttons functional so that when we press them they would send us to the appropriate example. In the setup section we set the character ‘0’ to the currentPage variable, which will indicate that we are at the home screen. So if that’s true, and if we press on the screen this if statement would become true and using these lines here we will get the X and Y coordinates where the screen has been pressed. If that’s the area that covers the first button we will call the drawDistanceSensor() custom function which will activate the distance sensor example. Also we will set the character ‘1’ to the variable currentPage which will indicate that we are at the first example. The drawFrame() custom function is used for highlighting the button when it’s pressed. The same procedure goes for the two other buttons.

So the drawDistanceSensor() custom function needs to be called only once when the button is pressed in order to draw all the graphics of this example in similar way as we described for the home screen. However, the getDistance() custom function needs to be called repeatedly in order to print the latest results of the distance measured by the sensor.

Ok next is the RGB LED Control example. If we press the second button, the drawLedControl() custom function will be called only once for drawing the graphic of that example and the setLedColor() custom function will be repeatedly called. In this function we use the touch screen to set the values of the 3 sliders from 0 to 255. With the if statements we confine the area of each slider and get the X value of the slider. So the values of the X coordinate of each slider are from 38 to 310 pixels and we need to map these values into values from 0 to 255 which will be used as a PWM signal for lighting up the LED. If you need more details how the RGB LED works you can check my particular tutorialfor that. The rest of the code in this custom function is for drawing the sliders. Back in the loop section we only have the back button which also turns off the LED when pressed.

In order the code to work and compile you will have to include an addition “.c” file in the same directory with the Arduino sketch. This file is for the third game example and it’s a bitmap of the bird. For more details how this part of the code work  you can check my particular tutorial. Here you can download that file:

Grant Road, Mumbai Shop No. 15, Ground Floor, Kennaway House, 63, Proctor Road Grant Road East, Grant Road, Mumbai - 400004, Dist. Mumbai, Maharashtra

Oriole Electronics is a pioneer of LCD technology in India. As one of India"s largest LCD manufacturer and exporter our Alphanumeric LCDs are used in a variety of industrial applications. Not only are the Oriole LCD"s known for their superior quality, but our RnD team is ever ready to help and support our customers technicalread more...

2.4 inch TFT LCD Display Shield Touch Panel ILI9341 240X320 for Arduino UNO MEGA Uses digital pins 5-13 and analog 0-3. That means you can use digital pins 2, 3 and analog 4 and 5. Pin 12 is available if not using the Micro-SD 5V compatible, use with 3.3V or 5V logic For Arduino UNO R3 MEGA2560 material:CCL colour:RED Packageread more...

Since you are the "video guy" when it comes to Propeller ;-), do you know why this 7 inch display with the VGA/HDMI/Composite board from SainSmart is not able to be used with P2 (Cluso"s and ozprop"s VGA code)?

On boot-up of the P2ES with the VGA code loaded (on the 7" display), The display changes its "no display connected" alert to a blank screen (this is good as that"s what it does just before it starts to display on the 14" monitor), then I get a white flash on the screen about every 3 to 4 seconds.

Note that this second technique will cause all files within a given application to be compiled in debug mode. The first technique will cause only that particular file to be compiled in debug mode.

I"ve been having trouble with that too! Let me know if you manage to find something that works? For now I"ve done a work around where the calibrator starts at every boot.

Today I found this site: http://www.tutorials-raspberrypi.de/gpi ... passungen/, followed the steps from saving the "99-calibration.conf" File and now it works just fine. Can"t explain it, removed the old file and now the settings are save and I don"t have to recalibrate after a reboot.

Today I found this site: http://www.tutorials-raspberrypi.de/gpi ... passungen/, followed the steps from saving the "99-calibration.conf" File and now it works just fine. Can"t explain it, removed the old file and now the settings are save and I don"t have to recalibrate after a reboot.

I am a newbie. I have purchased a 7inch Sainsmart LCD touchscreen and I am using raspian-wheezy 3.18. I have followed the steps in this post. I have followed the steps from other posts and sites: http://www.tutorials-raspberrypi.de/gpi ... passungen/ and viewtopic.php?f=41&t=21020. My touchscreen will not calibrate. My calibration process is to delete both usr/share/X11/xorg.conf.d/01-input.conf. and the ​/etc/X11/xorg.conf.d/99-calibration.conf files, reboot the pi and then try to calibrate. I have tried cailbrating with my finger and with a mouse. The results occasionally have SwapAxes = 1, but not all the time. No consistency.

I have viewed the log file looking for any clues. This section seems to be relevant to the touchscreen. Do I need to remove the mouse during power-up? Can anyone help me?

I struggled to with a Cintiq 13HD (no touch) to get the stylus to work, the above change solved the problem because the digitizer is handled as if it is a mouse device and needs a higher poll rate.

The monitor is a Lilliput 10 inch resistive touch screen. Jessie will work with the HDMI Monitor but it won"t recognise its 1024x600 display and defaults to 1280x760.

The main problem is the touch screen however. I have tried with and without drivers and the addition suggested to cmdline.txt. evtest finds input from the touch screen but not it seems at a monitored event. xinput_calibrator now downloads directly as xinput-calibrator but is still named xinput_calibrator in use (hyphen is the difference). This works but touch screen input is not recognised.

The monitor is a Lilliput 10 inch resistive touch screen. Jessie will work with the HDMI Monitor but it won"t recognise its 1024x600 display and defaults to 1280x760.

The main problem is the touch screen however. I have tried with and without drivers and the addition suggested to cmdline.txt. evtest finds input from the touch screen but not it seems at a monitored event. xinput_calibrator now downloads directly as xinput-calibrator but is still named xinput_calibrator in use (hyphen is the difference). This works but touch screen input is not recognised.

I"ve had similar problems with an eGalax 7" touchscreen running on Jessie using Pixel. Calibrating with xinput_calibrator throws up some weird x & y numbers and fails to work correctly.

This is renaming 10-evdev.conf to 45-evdev.conf in order to get it to load after 40-libinput.conf. Xinput_calibrator now calibrates for me and i am able to save the calibration data into /usr/share/X11/xorg.conf.d/99-calibration.conf and i have a woring eGalax screen on Jessie/Pixel.

I was just about to reply that this did not work but I tried a reboot first and the touch screen is now registering input with stretch and probably Jessie as well.

Thanks to (n1ks) and installing xserver-xorg-input-evdev on Jessie, my Lilliput touch screen is working correctly at the correct screen resolution of 1024x600 and touch is accurate.

I also had a problem with the screen size but edited /boot/config.txt to force the screen size I wanted and I also enabled overscan and trimmed the overscanning with a few trials. I needed to recalibrate the touch screen after this but now my original application is working with Jessie as it should.

I have set up xinput_calibrator as an alias that i can use in terminal for when the touch screen calibration is borked as i have no mouse or proper keyboard attached, it may help with your situation to run the command i use.

I launch xinput_calibration with startx xinput_calibration and after the 4 points have been touched both xinput_calibration and xterm exit and I can"t get the output.

I had same issue and [SOLVED] My problem. touchscreen was using xinput as default so be setting the Coordinate Transformation Matrix (115) i was able to have accurate moments with touchscreen. I use this command "xinput set-prop 9 115 1.060 0 -.035 0 -1.25 1.105 0 0 1" without the quotes. and bam my Y axis was inverted by negating the 3rd set of numbers eg.(-.035) but to make is stay on reboot i had to write a script to run to set this property again. also added Option "TransformationMatrix" "1.060 0 -.035 0 -1.25 1.105 0 0 " to the 40-libinput.conf file in the libinput touchscreen catchall section. file is located in /usr/share/X11/xorg.conf.d folder. This was necessary because if you unplugged usb and plugged it back in it would default. So by adding this line to the file it is read and reapplied.

After reboot, the LCD works. But the touches are all off, when I use the mouse to click on an icon, the correct icon opens the correct app, no a problem. However, this doesn"t hold true for finger tap or for stylus. when I tap on an icon with my finger or use the stylus. the mouse curser does not response to the correct location on the LCD. For example, when I click on and icon on the lower left side of the LCD, the mouse cursor stays on the upper right side time pi menu bar icon. It opens a calendar instead. I tried to calibrate it with the xinput-calibrator, pasted the data to the /etc/X11/xorg.conf.d/99-calibration.conf, reboot. Nothing changes. Have I missed some steps? Thanks.

This is renaming 10-evdev.conf to 45-evdev.conf in order to get it to load after 40-libinput.conf. Xinput_calibrator now calibrates for me and i am able to save the calibration data into /usr/share/X11/xorg.conf.d/99-calibration.conf and i have a woring eGalax screen on Jessie/Pixel.

(It looks like the Nook is probably my best bet, but it unfortunately doesn"t have a powered USB port so I"d need to find an external power supply of some description for the keyboard. Any other suggestions gratefully appreciated.)

I"m imagining literally just a CLI or rudimentary text editor with an e-paper interface... no video or images, just text. Very spartan. Response time is more than good enough for something like that.

Early LCDs had terrible ghosting (anyone remember trying to play Doom on an early mono LCD and the image instantly turning into incomprehensible hash?), but I can"t find any references for actual numbers for the pixel flip time. I"d be interested to know how they compare to eink. Does anyone know?

I will say the market might be too small. But if the market existed slow response times (which are still sub-second) would likely not hurt it too much for that usage.

For some reason the shiny, curved black plastic reminds me of a weird cross between Darth Vader and something a character in a Terry Gilliam film would use. Stick a Fresnel lens over the screen and you"re all set.

Even in non-power-constrained environments e-paper can be preferable - the glow of a typical LCD display is really distracting and doesn"t fit in a lot of (most) environments. Have enough gadgets around with LED displays and indicators and your home suddenly seems like a really bad 80s movie.

By themselves they"re not huge issues, but as you own more and more such devices it becomes really annoying to be surrounded by "smart" inanimate objects that constantly make you wait - even for a brief moment - before they are usable, and in that way they seem much less pleasant than the dumb objects they replaced.

Smart but task-dedicated devices should probably run the display/buttons on a dedicated chip that talks to the CPU asynchronously, to avoid this problem.

Your microwave and VCR are always on - their displays are also always on, so they don"t need to be woken up before being used, they are already awake.

A thermostat with an always-on screen is the same, they"re already displaying information and the touch screen can be immediately used without delay - but we don"t want the display to be always on, because in general LCDs look awful in their environments. In general people prefer their homes to not look like server rooms with blinking lights and garish panels everywhere.

So there is a non-technological need to keep the screen off, and this presents a fundamental problem - before anything can be done, the screen must first be woken up. No matter how fast you make this process, at the end of the day is one extra step that the user must do before the device can be used.

You can"t work around this with better software, because at the end of the day "activate device" is step 1, whereas with dumb technology step 1 is "use device".

The only real solution is for your devices to be always-on in a much more fundamental way - like your VCR or microwave - and that in some cases means e-ink screens.

EDIT2: I measured it frame-by-frame, it takes 5 frames from the moment the button starts to move until the screen is completely functional, showing the proper image. The video is at 25 fps, so that"s 200ms, for the whole device to go from non-powered to fully working animation.

With a device like your microwave (or your arcade game) steps 1 and 2 don"t exist, because the inputs are visible even when the screen is off. With your microwave you just walk up and start punching your desired buttons right away, the screen will catch up to you quickly.

And this is also why this is fundamentally a product design problem that isn"t fixable via simply faster software - a non-primed human will take 500ms+ at each of these steps just in reaction time, the 200ms wake-time and whatnot is minor in comparison to the delay caused by having the human take multiple steps to do something. This is fundamentally about modes of interaction and not really about software performance.

We are at a stage in tech development where human delays vastly overwhelm purely machine-caused lag time. This is why compressing multi-step processes into a single step (or eliminating them altogether) is so valuable in terms of improving usability. Conversely - and this is something a lot of futurists just don"t get - injecting additional steps into the use of something, even with very high performance software, results in disproportionate delays, and makes the product overall more annoying and cumbersome to use. This is the heart of why nearly all smarthome devices have been utter failures so far - despite doing something useful, they dramatically increase the human load on their usage.

Now, you could have a single home control display - or perhaps a single display in every room. And they"d all show the same information, maybe customised for each room, and include a few extra pages for setting up timers, lights, proximity sensors, or whatever.

There are plenty of applications for this kind of IoT, but the tech just hasn"t come together yet. I think the lack of good, cheap, large, low-energy displays is more of an issue than wake up times - because if the display uses very little energy, you can skip the wake up time.

Sure, yes, one reason we keep displays off most of the time is because of their usage, but more and more so it"s the secondary reason - there are lots of power efficient displays nowadays that can maintain an always-on screen at relatively low power cost, and smarthome devices generally aren"t reliant on battery power.

But the bigger problem is that LCD displays are ugly. They are backlit, and their response to better lighting in the room is to increase its own strength to make itself even more apparent. They are ugly, obnoxious, and annoying in the same way blinking router lights are, but multiplied several times over.

So we keep them off - we can afford to keep them on, but the fact that we keep them off 99% of the time less environmental consciousness but more an acknowledgment that they"re visually noisy, distracting, and just kind of don"t fit in. When you walk into a room you don"t want your attention immediately drawn to this LCD panel on the wall with its pale glow.

E-ink fortunately doesn"t suffer from this problem. It"s clearly legible, doesn"t require backlighting, and more importantly doesn"t appear distractingly electronic in everyday use. You can afford to keep an always-on e-ink display, not just because of its low power use, but because it won"t be this annoying glow in your peripheral vision always.

Being always on would be nice. You can work around not having it be so (I"m sure the Nest"s implementation can be improved) but the ideal would just be to have it always be visible.

I think those are much more common in new installations. These are segmented LCD displays. An eInk display would not require an explicit segmentation layout, so new layouts could be programmed on the fly, prototyped very quickly, etc. And might even be a little easier to read, even during daylight hours I find these types of LCD displays difficult to read, especially from off-angles.

I"m more inclined to do the 6 rows of 7 displays which allow for a day aligned calendar for every month. It wastes a few displays of course, but the displays are easier to get.

I spent this weekend creating a small micro-controller system (freescale uC) with an attached tft lcd+touch, the latter cost me less than a 1/4 of this display and uses standard connections and readily available datasheets.

In their own words, the raspberry pi display uses interface signals that most other manufactures shunned due to several issues (EMI,etc) and their connector is hard to find on any other sbc currently in the market.

The display is huge compared to the raspberry pi board, what is the use case, considering the low resolution? Why go through all the trouble of using the connector on the pi instead of its other standard hdmi port ?

I"ve been working with these types of LCDs for a long time, and when it comes to these WVGA/SVGA 7" units you can get a ton from Asia at great prices but the factory will literally disappear in a few months. The LCD fabs constantly get bought/sold/churned as the major players like Sharp and LG shed off their last-generation fabs and the other smaller fish scoop them up.

Ideally a group like RPi will want to have the same part available for a long time so that they don"t need to create new revisions of the interface cables, power supplies, or software drivers to handle the change. It"s nearly impossible to autodetect one 7" LCD from another via software so you need to configure it entirely in a bootloader or kernel configuration line. And then that becomes a massive support issue.

So the PCB part does this "adapter" work to make the screen "talk" with the R-Pi, right? Screens for mobile devices, don"t they have any standards someone can use to build a similar PCB?

Still cheaper to source these parts yourself, you are right, but the official screen isn"t meant to be the cheapest, it"s meant to be cheap enough to be affordable, to workout-of-the-box, to be reliable, of good quality and have some guaranteed availability.

You can work with other screens and build and write your own interface if that"s part of the pleasure you get from hacking on these devices, but for people who have other goals, being able to get an affordable screen that just works allows them to spend their time on other parts of their project.

Don"t get me wrong, i love the pi, and the problem is not the price tag of the pi + accessories but the unsustainable pricetag of entry level android tablets.

There is a recycling tax here that is as low as ~5 cts for a tablet or a comparable electronic device. The burden of recycling is on the developping countries we send our used gear to. Not to mention the use of raw materials.

"How many customers want to record video from an external source anyway? It"s not worth adding $5 to the MSRP for a feature that isn"t going to get used."

I ordered a Sense HAT from them recently and it arrived in a couple of days. It"s pretty fun BTW, my thoughts are here: https://unop.uk/dev/raspberry-pi-sense-hat

If the RPi itself had a charging circuit, they would have to decide for the end-users what kind of battery chemistry, charge rate etc. it should support, and they would not be able to please everyone as these things are used for so many different purposes.

I tried out Win 10 IoT a bit. You can find my thoughts in this post and the others linked from it. https://unop.uk/dev/windows-10-iot-core-on-a-raspberry-pi-2

I"ve got one myself as an attempted NAS device. It worked "ok", wouldn"t advise it as full-time thing though, these things don"t provide the AC nor CPU power to perform such tasks.

The vast majority of the cost of this display is driven by factors unrelated to the technology level. Labour to build it, logistical costs, EMC qualification etc. That"s the case for almost all cheap consumer electronics.

Sales volumes determine economies of scale, it is likely the £28 tablet was made in quantities much larger than the pi screen (I"d guess at least 2 orders of magnitude).

Also, not all screens are equal. It"s not just resolution: there"s colour reproduction, viewing angles, brightness, contrast and response time. On the non-technical side mentioned on the blog, they mentioned they wanted a manufacture who would make the panel for a long time. I would bet a dollar that Pi screen beats the £28-tablet display on all the above parameters

For a non-profit(!) like the RPi foundation that can neither guarantee sales nor buy them in advance in massive bulks, availability is the only factor that really matters.

narrow viewing angle, but wider temperature range[1]". The Innolux panel I mentioned in another comment here (https://news.ycombinator.com/item?id=10185433 ) is an example of this type.