We generally have a policy of not communicating externally by default (way too many startups have failed because of loose lips and over-promising), but I'll answer with what's already known publicly. :-)
> How many people are in your company?
Around 70¹.
> Where in Norway are you located?
Oslo¹ (or you can search for reMarkable on google maps).
> Are you looking to increase the number of people working in your company? Planning to hire more software developers?
> [...] is everything that the community would need available in order to create a fully open source alternative “firmware” (or really, a “distro” might be a better name for it since it’s running a Linux kernel and all) that can run on your hardware?
It's just a completely standard Linux system, and as required we publish the source code for u-boot and Linux and whatnot, so yes.
I originally wanted to just run plain Debian on it (or ALARM), but it was easier to just start with a minimal system and put on as little as possible, especially when you're a single person trying to keep track of everything.
Now we've expanded the team a bit, and ideally we could upstream at least the kernel patches so we don't have to forward-port everything ourselves, but it's not a high priority unfortunately.
And we're still a relatively small team, it's a bit hard to find a lot of good kernel developers who want to switch jobs in Norway.
> [...] but having a mosh console on there would allow here to ditch her macbook.
[..] Being able to code on it would also cause me to get one and ditch my iPad Pro.
Not officially supported or endorsed in any way, shape or form, and I don't even know if it even still builds, but I did a quick proof of concept porting fingerterm; https://iskrembilen.com/fingerterm+vim.jpg
I'm not trying to imply anything, but what I personally want and what we can do are two different things. I'm sorry if I've been sloppy in my comments here, the last days have been pretty hectic.
> If your software is closed source, then I don't understand how anyone other than you effectively (or practically) would be able to solve or fix any security holes.
I'm sorry if I wasn't clear. I meant that for pretty much all current e-paper devices you aren't able to get access to run your own code unless you find a security hole that you can exploit to gain access.
And sorry about the strawman, it wasn't intended that way. I think the rest of the comment before that answers your original question.
there are two epdc drivers in the kindle gpl releases. the source for the lab126 one is only available in the tarballs you linked (named mxc_epdc_fb_lab126.c).
as for the waveforms, I'm talking about support for the REAGL (sic) waveforms. grep for it in the linux source in the tarballs you linked to.
and e ink did not have a panel that met our requirements, and designed a new one after we talked with them.
edit; just to be clear, we don't use the lab126 driver, it was just an example of there being more drivers for the imx6 generation epdc.
Again, I can't discuss too many technical details. But yes, it's an i.MX6SL, I thought we mentioned that on the web page.
And there are actually several drivers for the EPDC available. Two from freescale for the imx6 and imx7 (though there are some other improvements in the _v2, apart from imx7 support). There's also another one written by lab126, but I'm not sure if they actually use it. there's also some minor variations in the drivers in the different kernel branches and trees from NXP. And then you have the u-boot drivers. And I think there might be one in the bare metal SDK, but I haven't looked. And then you have the 5bit waveform support, which is a whole other story (with iffy GPL implications for some vendors I won't name).
And the display was designed based on our requirements, but we don't have any kind of exclusivity on it. there's already other devices coming out with it (you can find them if you google the specs, especially the awkward resolution we got thanks to the limits of the technology and our DPI requirement).
it won't take many weeks (or days) from we release the device until our solution is reverse engineered, no matter how much we lock it down. but until then we want to keep as much as possible secret.
as for hackable device; we don't intend to release the magic sauce that makes the latency goes down. what I meant with hackable is that I've wanted an e-paper device which I could run my own code on, without having to look for security holes in the software running on it.
but again; we can't promise anything at this point wrt. hackability; we have limited time and resources, and our focus is on making the device as good as possible. our focus is not on making an open source device, we're not going to release the gerber files. :-)
just to clear up any possible confusion; don't expect text recognition.
it's probably the most requested feature, but it's a really, really hard problem.
but please send me a message at [email protected] if anyone have any tips about solutions to this (we're talking with a couple of vendors, but we might have missed some).
this is one of the reasons we need to get this in the hands of some kind of ambassadors that can test for themselves and give us some validation. imho the video doesn't do it much justice.
the reasons we decided against usb c are a) the device would have to be thicker, b) our industrial designer didn't like how it would look, and most importantly; c) I still have a hard time finding usb c cables. I always have to bring my own.
we went to CES this year to see if there was any reason for us to go, but based on that we decided not to. it's insanely huge and hard to get any kind of exposure, even if people knew about us beforehand.
but seeing is believing, especially with this product, videos doesn't do it justice imho. so we need some way of getting it into the hands of people, probably some kind of ambassadors that have some reach and a lot of integrity. but this has to wait until our ODM finishes the next batches of prototypes, so we actually have devices that we can send out.
of course, one of the nice things with modern hardware is that we can deliver more features after shipping the device.
edit; also, it is a device connected to the internet. not supporting updating the firmware would be extremely irresponsible from a security perspective.
these uncertainties is why we hired Dragon Innovation early on. they're very, very good at this and has a very good track record when it comes to hardware startups (e. g. pebble and makerbot).
"best developers" was a bit tongue in cheek, it was late and I didn't have time to come up with good wording (I'm not a good word person). but what I tried to convey; we know that even _if_ we can release a toolchain, we can't deliver a full, polished SDK. so "best developers" was more about developers that don't need any hand-holding.
but again; we can't even promise that we have the time and resources to package up a usable toolchain for third-parties.
:-)