Okay. Looks like my mic's working, so that's always a good start. Thanks everybody for coming to Grocking the Linux Spy subsystem. My name is Matt Porter with Consulco Group, and let's dive into it here because I broke my rule about how many slides to have in something because there's just too many visual aids needed in this. A little background on this. If you're somebody who works in the spy subsystem itself and the core code or you're already doing controller drivers, probably not the content you're looking for here. This is more from that person trying to use it, right? How do I actually make use of this stuff? So let's get going. Oh, turned it off already. Of course my pointer quit working again. Alright, so one of the things I try to do is that we get reminded a lot that we have a very diverse community these days, and so I got to unobfuscate the title of the session. So Grock comes from Stranger in a Strange Land. That's where the book comes from. That's actually one of the cover art things. So now you know if you didn't know where that word came from. So we're going to go through today. We're going to talk about what spy is. We can't really talk about how the subsystem works and what the facilities are available to us as users, whether we're kernel users or user space users until we actually understand it completely. And so we'll go over spy fundamentals, some Linux specific spy concepts, and then we'll look at use cases, these kind of use cases where at a device we want to do a protocol driver, controller driver, and we'll talk about what those mean in this context, and then user space drivers. And we'll talk a little bit about spy performance and then what's coming up in the future in the spy subsystem. So what is spy? Yes, not as many people in Europe get this reference. I noticed, but more people in the U.S. will get that. So serial peripheral interface. It's a Motorola de facto standard. This comes back from HCO8 microcontroller time frame. They had introduced this right around there. For any of you that started in university working on HCO5, HCO8s like me, dating myself, you might have seen this stuff back then. So it's a master slave bus. It's a four wire bus, except when it's not. So nothing is simple. And there's no maximum clock speed, right? So we can go maximum ludicrous speed like a Tesla. And one joking comment about spy itself is that it's just a glorified shift register, right? Or shift register with side effects. So if you want to get into the more detail, gory detail, you can go to the usual source of knowledge there, Stack Overflow, of course. And hope that people haven't defaced the page. All right, so let's talk a little bit. Common uses of spy were embedded Linux engineers or budding embedded Linux engineers in here. You probably have seen some of these. Maybe you didn't know all of them. But just to give you an idea of the types of peripherals that have spy bus support, flash memory is a big one, okay? A lot of spy flashes, analog digital converters, very popular. A lot of sensors, thermocouples in particular is one type, LCD controllers. The Chromium embedded controller has a spy interface to name some one particular thing in a known product. So a lot of different things. And a lot of these have one characteristic in common. They're actually relatively high data rate peripherals compared to I2C peripherals. So that's a little idea of the flavor of things we see with spy. So let's talk about fundamentals. So we really need to understand first what the spy signals are that we use. And so pretty simple, the defecto standard name. And so we're all driven by the original Motorola naming for that. So we'll tend to see MOSI or however you pronounce it. That's how I do it. Master Output Slave Input. But as I show here, there's lots of other names for it when you start looking at data sheets and your user manual and so forth. You'll see SOMI, you'll see SDI. You'll even see I2C naming, which is kind of a little bit of a problem sometimes on data sheets. MISO, Master Input, Slave Output. And the name gives you a clue of what direction things are going. That's the beauty of those. Same naming issues, because it's a defecto standard, people will go and adjust things a bit in their version.  So this is the simple, basic, original way that SPI shows up, the basic symbols. And the slave select that's also known as chip select. And we'll see that that's how it gets referred to later in the kernel stuff as well. Okay, so wow. I am excellent at drawing diagrams, as you see. So with the little help from tools, so that's about as good as it gets. So we like things simple. So first we show the most simple thing possible, right? Those four signals, right? Exactly the directions I promised them, and everything marvelous, right? So now we want to look at timing diagrams, because timing diagrams are important in understanding SPI. So the best thing to do is take a look at what a basic 8-bit read and write will look like on SPI bus. So here we see data's not stable to these spots, okay? So we've got some bits. Notice that we're doing the most significant bit first on the wire here, okay? This is a write mode. We'll talk about modes in a second. That's a very important part, concept to understand in SPI. We don't care about the master in, right? This is a write, so we're only seeing data on this Mosey line, okay? On the read, converse happens here, okay? And so what you see is you see the chip select line, okay, being asserted low in this basic thing through this whole transfer, or we'll just call it a cycle for the moment, okay? And you'll see that the data here is latched, okay? On the rising edge, okay? And the same thing's true, okay? On a read. And you'll see that the chip select went low during that whole transfer. So that's your basic transfer, simple, right? So now we need to understand SPI modes, right? I hit you with SPI mode on there. I don't tell you what it is. Now I'll tell you what it is. So it's essentially a clock polarity and phase of the clock relative to where we're latching the data. A very simple way to look at it is that when you have clock polarity, where the idle state of the clock is low, then your C pole is zero, okay? And if the idle state's high, then it's one, okay? And then clock phase, it's simply data is latched falling and output on rising, and one is data latched on rising, output falling. We're going to take a look at this visually because it doesn't always make sense just with a bunch of words, right? But if you understand the simple binary there, then you'll see that mode numbers are a simple mapping in this table. So those mode numbers you're seeing zero, one, two, three. As you see references in SPI, this is what they mean. And then we're going to show you what it looks like in the timing world. So you can see why I'm using a lot of laser pointer now because it takes a bit to look at this. So once again, we're looking at one version of what I showed before. And so we're just going to look at writes in this case. So in each case, I just drop out the meso line. We're just looking at output. And so I've got data here, okay? My clock is idle low as I promised, okay? And write mode zero. Data is latched on the rising edge. So that corresponds back to that mode zero, okay? Write mode one, my clock is idle low, all right? And it clocks, but the data is getting latched here on the falling edge. And you see falling edge lines up with where our data is stable all the way down. So that's write mode zero and one visually. And then now when we go to write mode two, these are both where C poles one, okay, on the slide. And so what you see is our clock is idle high, okay? Data is latched on the falling edge.  And the same thing, our clock is idle high in this case. And it's latched on the rising edge in write mode three. It's that simple. Works the same way when you're doing a read, but we just need to show you the cases in just a write to simplify the timing diagram. Okay, all right, so great, simple, right? We know everything we need to know about SPI, except it then gets more complicated in the real world. We have lots of simple cases that work like that. You might just have one device, but the reality is you're going to have quite a few. And that's where your chip select comes into play, okay? We showed on the timing diagram, that chip select being asserted low typically when I was showing the mode zero examples. And each slave has a chip select, okay? So if you have multiple SPI slaves, you would have the chip select being independently asserted to handle so that it would handle that right, okay? The next thing that you see is there's daisy chaining and there's a common type of daisy chaining where it's the inputs to outputs, okay? So of the devices. There's another rarer one which is where chip selects get daisy chained. And I see one person perplexed by that. They've never seen it, but that's the beauty of de facto standard. Everybody can do whatever they want. And I can tell you that the anodyme field program or analog arrays actually do this chip select daisy chaining which is super ugly. So lots of ugliness. Then we get into some cool stuff. We talked about flash, right? Being a big use case, right? And it started originally as these single lane flashes and now, okay, instead of one miso, you can have n misos, okay? It's a little bit more complicated than that, but on a read, you can have dual or quad misos typically in those devices. And of course, now you have n times bandwidth when you're doing reads which is that fast path that they're trying to optimize, okay? And then we have the micro wire, three wire variants, the one I promised except when it's not four wire and they handle half duplex, okay? Well, half duplex. So miso and most of you are combined on the same line. So a few different variants of that. And again, another one of my masterful drawings where you see how you hook up three different spy slaves. Notice as promised that there's multiple chip selects. I'm using the original terminology slave select there. So you see slave select one, two, and three are only routed to each of those devices and all the signals go appropriately to all three devices, okay? So one master, many peripherals or slaves. So now, if you can see this eye chart and apologize, I can't point to both sides. But now we look at multiple slaves. What does that timing diagram look like? Well, it's exactly the same except we've got three chip selects. Again, I just have to pick one mode for illustration purposes and we're latching on that rising edge, right? And the clock was idle low, right? We're latching on the rising edge. But notice that the chip select, right? Before that clock edge where it's going to latch, it goes low for that entire cycle. Then here, this next set of data on slave select two, okay? And then slave select three. So pretty straightforward there. And those are the basics, fundamentals. So now we can talk about Linux stuff. All right. So conceptually in... Let me get my... Here. All right. So now conceptually with Linux, we have the concepts of controller and protocol drivers, okay? And controller drivers support a spy master device. So when we looked at that fundamental piece of hardware, whatever houses that peripheral, that IP block, right? Normally in our SOC these days, that's the driver that runs that hardware, okay? And so things are carefully separated in the spy subsystem so that everything for the controller is just the basic pieces to do clock control, chip select control, think back to our signals, right? We're dealing with that zero clock signal, right? The chip selects, right? And then running that shift register that we talked about, right? And there's a lot of details involved in that, but at a high level, it doesn't know anything about your end peripheral, right? Now, so an example would be take the Raspberry Pi series, the BCM2835 AUX driver. That would be an example of a spy controller driver you might use, okay? So now protocol drivers, they support whatever's needed to drive the actual functionality of that spy slave in our block diagrams, right? And so this is completely based on a concept of messages and transfers, which is Linux terminology, okay? And we'll talk a little bit more about that. And the protocol driver doesn't know anything about your controller driver, right? So it relies completely on the controller driver to do all that chip select work, right? All the shifting and stuff, so it's neatly separated, all right? So an example there would be, let's say you were using a ADC in the IIO subsystem like MCP3008, that's a protocol driver. And if you're familiar with SpyDev, which we'll talk way later about in user space stuff, that is an example of a protocol driver as well. Okay, so how do we do communication in the Linux Spy subsystem? And so fundamentally as I promised, the communications are broken up into transfers and messages. And so a transfer is a single operation between a master and slave, okay? And so the structures, the transfer structure has things like transmit and receive buffer pointers, okay? It has fields to control chip select behavior after operations. What's the behavior of that chip select as to whether it becomes de-asserted in between transfers before the next one? And we'll talk a little bit more about that later, and how tricky that can be. And things like you may need a delay after your transfer. So all this goes into when you're looking at that data sheet for your peripheral, it has timing requirements, and it may need a certain span of time before you send that next transfer, whatever it is. It depends on the protocol it implements, okay? So you're able to define all those things in there, in a transfer. And then a message is just an atomic sequence of these transfers. And then a message is actually that fundamental argument to all the SPI subsystem transfer APIs, all right? So basically imagine a link list of transfers, right? And another great diagram, right? So that's what a SPI message looks like. So now let's get into use cases, and that'll take us into how we do these various things. So if we explore some of these common use cases that people need to do, the first thing people seem to want to do is I need to figure out how to hook up this device that's on my board I've got, right? And there's already a kernel driver for it, right? So that's one. The next thing is I need to write a kernel protocol driver, and then the next big thing, and less common, right? Because most of them are written for us, is I need to write a kernel controller driver. And then finally, one of the big ones, and you see kind of, especially from people doing testing and some of the maker-type projects in user space, is I want to do something in user space to drive my SPI slave, okay? All right, so let's jump into adding a SPI device to your system. So the first thing is we need to learn how to read data sheets because a lot of people can't seem to read data sheets. So we're going to force you through reading a data sheet very quickly. And I'll show you what I mean by that and the type of things you need to pick out. But there's three methods, okay, after we do go through that, that we hook up a protocol driver in our system. And first is the ubiquitous device tree method that most of you will use. Then there's the board file method, which some systems will still use, especially old vendor trees. If you're unlucky enough to be there, sometimes some of the x86 stuff because ACPI is tough to use. And so you'll see the latter two, mostly on x86 and vendor kernels these days. But we'll look at all of them. So yeah, so now we learn how to read a data sheet by me picking out a few things. So you're looking at a data sheet and it's like, what is this thing?  It might just say it's a three wire or two wire or something synchronous serial interface. And so you might have to do a little detective work on that. The next thing that's important is you're going to start remembering these timing diagrams and saying, gosh, it's a good thing it told me SPI because it's showing me here I2C signal names. So that's the proof that there's data sheets that show you. This is really out of the ST7735. And if you've used like the FBTFT driver, this is one of the parts that's supported in that. So real device. And so the idea here is you need to remember things like I need to figure out what's the maximum clock rate that my device can support, right? Because I need to tell the system what the max clock rate is when I'm hooking up a device. It's one of those critical things, right? So you're going to have to be able to read this timing diagram. Well, it maps exactly to what I was showing you because, and my resolution's awful here. So you look at these two values. You look further down in the table and you find the hold times on these, right? And so you can get with simple addition, you get the period and if you're any good at math, I hope you can do minimal math, you get the frequency, right? And so you've got to, with those minimums, you now have a maximum frequency out of that, right? So those are the kind of things you're looking for. Don't always expect to see spy jumping out at you or it's saying, hey, your maximum clock rates this, right? You need to actually read the timing diagram and understand it. Same thing goes when you start getting into the protocol pieces and so as we get down here, further down in the data sheet, it's one thing to have that timing diagram and what the clock looks like for the individual bit clocking, right? But then when you get into the specific protocol of this device, now it's showing me what kind of delay I have to have between the transfers, okay? So there's a delay here minimum and so that goes into things where I showed you with the transfer thing, you know, optional delay between transfers, you may need to set that depending on how efficient your protocol driver is trying to be. If it's trying to maximize the bandwidth on there, you're trying to optimize exactly against this timing diagram to get your best performance. So important that you understand and can read those. Just another example here with the MCP3008. I'm going to use this a little bit more in this talk but it's good to show you two examples. Here they told you what modes it uses too, okay? Gave you a little bit of information. Don't get confused about conversion rates. It has nothing to do with our actual spy clock and again, same kind of things here, right? T high, T low. We're able to jump into here and see, okay, you know, my minimum, if I didn't clip this off, those are minimum high and low times, right? So we got a 250 nanosecond period and we can get our frequency or max frequency out of that. All right. And again, same thing holds true. That's just the basic what can I do with a clock but I also have this special protocol, right? I got to send it commands of when to do an actual analog to digital conversion and then it's going to send me data back and so there's start bits, there's certain delays and so you're going to have this protocol specific stuff that you're going to have to figure that out for your peripheral if you're writing those. If you're just using an existing driver, you know, you probably just need to know that, hey, I need to know what the max frequency is if I don't have another example, right, on the web somewhere or I have a variant because you'll have, like in this family, you know, there's like 30 of these chips, right? And they all have different zero clock maxes, right? So if you want to get the maximum rate, you want to go double check that before you hook it up. Alrighty. So now we get into the examples and I sure fixed this from doing this at FOSTA because I had a black background, that was terrible. So first thing you want to do is this is all about showing you where to get the information. We're going to use this MCP3008 all the way through for all these examples now, okay? So the first thing is you need to know where to find device tree bindings, okay? If we're doing it device tree-wise. So you're going to use your documentation source. Either you're hitting Google and you're seeing the LXR tree and free electrons hosted kernel stuff to read it there or you're looking in your local tree and down in the documentation device tree bindings directory.  Well, it's one of many chips in this binding and this is kind of trimmed a little bit so you can see, but they show you, they show you here. Now I'm favoring this side of the room, of course. In that list, right, is a compatible string. And just to point out, this isn't grocking device tree so I expect you to know at least the basics of that first because there's not enough time to do it all but you need to know that compatible string and of course they give you the example this should be familiar to people working with device tree. But what's important with spy is there's the reg here and spy max frequency. So this is actually the chip select number. So that's a unique address on the bus essentially is how that works out in the driver model and then your spy max frequency that we're really talking a lot about here. So that's why we needed to know that. And so that's an example, shows you how to hook it up. Now, one thing I improved here was that somebody had a question of where did these IDs get picked up, right? Well, here's, you can see I kind of trimmed some stuff out here just so I could fit in on a slide. So you have in your driver this mcp320x ADC driver you have this ID list, common pattern. You'll see this for other data structures like ACP IDs we'll show an example of that as well. So you see this common pattern in the kernel, right? So if you look at that driver, you'll see that it handles this compatible string here, right? And then that it's able to bring in some chip specific info for that variant of the family, okay?  If you're wondering where this comes into place, it's all part of that driver definition that's all part of the driver model, okay? So nothing surprising here, but at the end of the day that's how that compatible string gets matched in, right? And if you have any confusion of what it's using, you always go to the source and look at this, okay? Last thing is, I showed you where the driver side was. I showed you where to get the binding information. Now you actually have to use it. I'll show you in this case, and the overlay fragment syntax is changing as we speak. So that's a whole nother topic, but this is at least a old style version. It is what it is, right? So what you see here is exactly like that example in the binding. We hook it up, all right? And that's that max frequency we got out of that period, right? That we got off the 3008 thing. So you do something like that. If you're doing a static DTS entry, the syntax is a bit different, but obviously the meat of it here is the same. So we went end-to-end on that, hooking up that via DT. Not much different with the board file, right? Don't use board files though. I'm just showing you don't do this, okay? But that's where you would hook up the same things. You notice chip select zero. You have to mention the bus number for the actual master here, but essentially the same info there, and you use mod alias to hook it up to that module. And it gets in there either if it was an old board file and build in the kernel, or sometimes I saw people on the mental board project just writing a module and doing this because it's too hard to do via ACPI. All right. Did I say it was too hard to do by ACPI? It is possible, but as you see, it's not designed for humans to read or at least not for me to read. But what you see is if you were to do, instantiate a spy device by ACPI, you have the same things. You're telling it polarity, all these different specs. But the most important thing is the max frequency, which of course they have in hex, so it's not readable. Well, it's readable, but that's ACPI. All right. So the first thing is they follow a standard driver model, just like everything. And when I'm hooking up a driver, I show you the driver IDs, and I show you all those pieces. It's all standard driver model. It's just spy using that. And so I want to do a protocol driver in the kernel. I need to do some basic things. And we don't show everything. We don't show everything. But you need to find that driver structure, right? Here I've got my protocol. I need to have some power management ops. Those are all implementation details for your part. But I need to have an entry point, probe, and remove all standard driver model stuff. Once you enter the probe, though, you can immediately start working on it. Once you enter the probe, though, you can immediately start using kernel APIs. And we'll talk about the kernel APIs now. So kind of diving in from that use case perspective. So what are the kernel APIs available to these protocol drivers? Well, pretty simple. Two big categories, async and synchronous, surprisingly enough. First you have spy async. And so it's an asynchronous message request, surprisingly enough. And you get a callback executed when it completes. You can execute those in any context. And what does that mean? We'll mention down here. So if we go to spy sync, it's a synchronous message request. And we can only execute in a context that doesn't sleep. So in a common case, don't do it in IRQ context. All of these later things are all wrappers around spy async. So there's not any real magic going on. It's just that thing's going to wait for the transfer to complete and then return to you. And then there's some helper functions that, again, wrap around spy sync, spy write, and spy read. Recall that I said that the message is that fundamental argument to everything. So when you're using these, you're handing it a message with just a list of these transfers. And you're going to define those transfers as whatever satisfies the protocol specific to that part that you've carefully studied the data sheet for. There's some other ones for special use cases. We mentioned how flash devices, commonly now, especially, are dual well mostly quad now, quads by capable. So there's optimized routines for those. And also these are optimized because of the quads by things being such low pin count. They're replacing NOR flash, old style parallel NOR flash, because the speeds are very similar now and the reliability of those. And so there's actually, I think, take, for example, the DRA 7XX stuff from TI. They have an MMO controller that translates into flash commands. And so it can actually XIP out of these spy flashes that way. Then we have these other helper APIs that allow us to create and build up that message. It's that list of transfers. So we need helpers to help us out here. Spy message in it, add tail. Some of those patterns will look familiar as to other subsystems in the kernel and how data structures are managed.  All right, so that covers protocol drivers, controller drivers. Again, standard Linux model. You first allocate a controller with spy alloc master, and then you set controller fields and methods. We showed just the basics. Common mode bits, for example, all these flags. You show what the capabilities are of the controller. Not every controller can do spy RX quad. That would apply to those controllers that can handle the four miso lanes, for example, in that mode. Spy loop, where it can do a loopback in hardware. You have to implement setup and cleanup, and you need to implement one of these. And many of the masters, they've moved to the transfer one model because that allows you to let the core support GPIO, chip selects, and there's a lot of demand to expand out chip selects. Or because there's a lot of controllers that just don't even have a hardware chip select mechanism, that's necessary as well. So you'll see this implemented more commonly on some of them. And then finally, when you've got that all set up, you just register master. All right, talk about user space. Yeah, well, all right. So user space driver, probably many of you have heard of spy dev or used it and so forth. So it's intended primarily for development and test. In reality, we know that everybody's got their Python and GoLang and Ruby and every other thing built on top of it to do their maker cases. So very popular for people doing hobbyist projects and so forth. But in many test scenarios. If you're using that common DT case. Well, first let me say, normally you're going to want to write a kernel driver. You're not going to want to do a spy dev user space driver. You're going to work hard. Probably the reason that you were using spy in the first place is that it's a high performance part. You're better off doing a kernel driver and everything, but there's obviously lots of cases where you just want to whack at something and have maybe a test case or so forth. So I mean, that's really the most common place of use where people are just hacking around with it. So super useful, but how do we hook it up? And so you can leverage in upstream one of these compatible strings because you're just kind of doing some testing and stuff and then you don't have to modify anything. I mean, if you needed to put something extra in there, you could and I know sometimes accept new compatible strings upstream where it's a legitimate device that's not going to ever have a kernel driver. And then finally, in the spy dev driver, the other way you can hook it up. Well, you can do the board file method, exactly how we showed the other one, but the ACPI IDs that are supported, you can use those if you're doing an override, an ACPI override loading. So you can do that or you can modify your vendor kernel and add something else. So that's how you hook that up. All right, so what happens? Once that driver binds, okay, we've hooked it up. It binds. The magic that happens is that we have this this class spy dev devices get created and so bus is your master ID, numerical ID, as they're allocated in the system and then there's a device for each chip select. So if you had three chip selects, you're going to have bus 0.0123, okay? And then you also get the dev spy dev same thing, okay? It's a simple character device, open, close, read, write. I say read, writes, half duplex, right? The one thing I think I neglected earlier to say, inherently, if we go back to the beginning and look at that spy bus, right, it's inherently a full duplex bus, right? Every time you're clocking a bit out, there's another one coming in. However, in your protocols, right, you will find that, you know, some parts, like the ST7735, you don't need to hook up MISO. It's a one-way path, right? So when you're actually, if you think back to the transfers we looked at before there's TX and RX buffs, the trend you'll see, you're delivering data in one direction. So if I'm transmitting, I've got an actual buffer and in that transfer, so I've got a pointer to a buffer, but if I'm doing a write only, okay, then my RX buffer just points to null, okay? And so that's what happens here. If you were to just write a byte, okay, with the write call, it would, behind the scenes, what would happen is it generates a transfer where that RX buff is pointing to null, okay? So many times you don't want to do a half-duplex transfer, right? A lot of devices, you're reading something back simultaneously and so you're gonna have to go to the IAC tool interface and so the options you have there are the same, map exactly the same to those kernel APIs, right? I want to send a raw message. It's full-duplex. In that interface you can define your buffers, right? Filling the receive and having that transmit buffer sent, okay? And you can also define your chipselect control, okay? And that, sorry, chipselect control. So all of those options, we showed a few of those, how you could change the behavior or the delays after transfers. You can do all of that through spydev here. Finally, there's a complete set of parameters here that you can set for both read and write cases, all right? So you have complete control over that. And as you get into the details of this, so showing this in slides and this much content, that's not the whole deal. I kind of, you know, show it broken out so you know where to look. But if you want the gory details on that, as always, the kernel docs are the way to go. And what's really great is, and sometimes people forget that the tools directory exists, right? Except by references when people are talking about things on the mailing list. Don't forget that you have tools spy these two examples, right? So it's a full-duplex example, all right? That's really great for getting started. You want to write a test or something in there. And then the spydev test that was written, which is outstanding, tests all kinds of different cases. Exposed all kinds of problems and various controller drivers.  It's, I think, a nicely written piece of C code, very easy to follow and everything. And then what's also popular in the maker community on top of that is the Python spydev binding, that particular one. There's a couple that's the most popular that I see used most of the time. All right, let's talk a little bit about Linux spy performance. One of the things you have to keep in mind, we talk about all this nice abstraction, right? And abstraction is great, except eventually, sometimes you find these holds and things where you have to start knowing how the hardware works, which is sort of like when you need that last 10% performance that takes 90% of the time, right? And so there are things like, and I just give examples, you need to be aware of what that controller driver does when you start thinking about performance, because you may run a test case and, in example, this OMAP mixpy driver, okay, it has in the controller driver a fixed, there are no heuristics of when it engages DMA. It simply says if it's greater than 160 bytes, the transfer size, I'll use DMA, otherwise it's too much overhead, right? It's a typical, typical type thing, but people have been, and I saw it firsthand, confused by the fact that, hey, DMA is not happening, we don't understand why. Well, they were doing 128 byte transfers on this driver. So you need to be aware of that. There are other cases very specific to various controller drivers when you start looking at the thing on your logic analyzer or whatever tool you're using on your scope and you start seeing that there's delays in it, you need to start being aware of those types of things in the controller driver, how they manage their chip selects would be other areas that may not be optimized very well. And then the next big area is you need to know when to use sync versus async, okay? You'll find most kernel drivers are using synchronous calls. You'll find that there's some network drivers are the big users of async, right? And actually it's fairly rare, but that's the big place and it's because they're optimizing for bandwidth rather than latency, right? And that makes perfect sense there whereas everybody else really wants to get that little transfer out on the wire as fast as possible, right? So they're typically doing the sync. One of the nice things that came in in the 4x series was that sync will now attempt to execute in caller context and that's made a big difference. So it will rather than sleeping, it will try to execute in that caller context so further reduction in latency. So it aggressively tries to do that if possible. And then this big one, okay, talked a little bit about how you can set all these different options in your transfer structure, right? When you're building up your message and you're creating transfers, you need to understand that the characteristic again of that slave device, right? And what it wants to see optimally because, for example, if you have a protocol and you allow the chip select to go back high after each transfer, you add extra timing delay in between the transfers. Your particular chip, it might require that, okay? It may not. Some of them can handle stringing them together and just leaving the chip select asserted. So as you can imagine, if you don't have to have the controller driver, de-assert that chip select after each transfer and then reassert it and you're going to the same device, you can improve performance in a way that you can quantify when you're looking on the logic analyzer and seeing that all of a sudden, okay, now I can string these transfers together and hit that maximum timing diagram they showed me in the data sheet. So this is the canonical good explanation of how that CS change field works. And, you know, it's a pretty detailed one, right? But that's how you actually manage cases like that. So if you've got a part, right, where you want to have... where you want to control that chip select in any of those different variants, you do it here, okay? So the important thing there, this is in the spy header, right? Most of the other important docs are in the actual documentation directory, but this one I think is... you know, CS change is mentioned, but it's often confused and it was actually implemented wrong in the IIO subsystem for a long time, in fact. So, yeah, they fixed that up. I can't remember where I saw that coming in, but they realized it was wrong for a while on that when someone was doing some performance analysis. So keep this in mind as well. And the other big thing is, you know, there's no excuse for not having good performance and debug tools these days, right? So you have to have it if you're trying to get decent performance because you can't fix what you can't see, and so, you know, you can look at these resources here and actually prefer SigRocSource, right? Because they have a great comparison of everything they support or don't support there for logic analyzers. So for things that are now well under $50 U.S. and have been for a while, there's really no excuse not to have even a simple one. The other thing is you can use spy loopback test module, the self-test for some performance work and also debug of controller drivers, so forth. That's very useful. It's exposed a lot of problems. And then finally, one of the newer things, relatively new, that came in is this great set of statistics. And so now you have under sysclass by master and now bb.c, so that's bus, chip, select, right? Same notation we're looking at. Kind of makes sense based on the allocation of the driver. You have these statistics nodes, and so you have statistics on messages, transfers, errors, timeouts, all those good things you want to see. And also, you know, I talked about how it tries to optimize for executing in caller context, right? So you're writing a driver or you're doing something spy dev, you can go look and see how many times it did that transfer with spy sync and how many times it actually executed in caller context, which is what you really wanted, right? To avoid if you're going for reduction in latency. So you can use that to start, you know, having that information. The other cool thing is when you have something that's complex with maybe many devices, I got histogram on transfers. So you can get that data out, okay, of what size buffers are getting transferred and stuff. And that's actually interesting to see as you start debugging how different messages and transfers are occurring. Maybe you're looking at DMA efficiency and so forth. Having that kind of analysis of what your system's doing with multiple protocol drivers can be really useful in diagnosing things. That thing is flaky. Okay, and time check, we're doing it. Real quick on spy future, so slave support is coming. Actually, I didn't look in the last couple weeks where we're at, been traveling, but so hard real-time issues, right, on Linux and the inability to have very tight-time constraint determinism has made slave support kind of problematic in a generic way. However, Geer De Hoven noted that there's a lot of use cases that you can implement that are real-world use cases if you kind of limit what your scope is of this. So he had mentioned pre-existing responses. So you have a slave driver and maybe it's time of day. It's ready to return and it's got that transfer ready. You can implement something of that, or commands are just one way, right? And so currently has a V2 RFC patch series. Looks pretty good now. There's a bit of work to do on it, of course, and he mentioned some bugs and so forth. It works just analogously like registering a master with Spy Alex Slave when you're adding a controller driver. And then the way it works is he has this type of node that gets exposed after a slave controller is instantiated and you can write slave protocol drivers that are bound by a CISFS like this. So if you have a slave protocol driver, go that in and that binds and activates it. And he provides in that RFC patch series on the previous slide these two examples, which actually map neatly to those two use cases. He says where this Spy Slave Time just sends the latest uptime back, just an example of that type of use case, and then Spy Slave System Control, which is power off reboot halt system. So it accomplishes those. All right. I think we have questions. I have the sync and the async. And I have a protocol driver that we can do. As I understand it, SPI queues the messages up and then we burst the queue out twice. And we may or may not get an answer or reply at that time. You know, when the send queue empties, we're also going to receive queue because I'm paying it directly. Are you talking about actually on that slave device or in the subsystem? Now, the sync versus the async. Okay. When I fill a message queue and I call the sync or I call async, does it immediately empty the queue through the hardware or DNA mechanism to be sent immediately? Or is it a budget command? The spy sync will try to execute that immediately. The sync will. It can sleep though. It can sleep and block. Well, not block, but sleep. You don't want it to sleep. So you could use spy async and just hook a callback. That's what... I forget which network drivers. I didn't think it was ENC. Somebody might remember... Do you know... There's one that does that and is a great example of... There's not many examples of it that I know of. Yeah. But it works in the network driver type thing. So yeah, it's very limited use cases. So speaking of interrupts... There. Let's say I had an SPI device that... I mean, SPI inherently doesn't have an IRQ, but if you have a GPIO that says, hey, I need service now. Can you talk to how you would tie that in? Or is there a way to have SPI pull in the background to see what... So there's a separate subsystem for these things. The GPIO subsystem offers all... I get to say disclaimer. That's out of the scope for this talk now. Different talk, right? But the GPIO subsystem... So when you're building a protocol driver, again, this is all simplified. That's like an everyday case, right? That you've got the IRQ. That's out of the bounds of SPI. But in reality, when you're writing that protocol driver, one of the other resources you have to hook is that GPIO. And you need to request the GPIO using the GPIO framework and set it up as an interrupt, okay? Well, you just request an interrupt. Ignore the kind of GPIO. You don't want to read just the GPIO. Right, right. When I say get the resource, talking about all of that, the same hookup you do, you have to say in device tree you need to specify that here's the GPIO for this device when you're instantiating the device, right? The subsystem. His specific question was about interrupts and how interrupts are handled. And so, yeah, the clarification is that that is not something that's part of SPI just by the very nature that's not SPI. But that's where you're using the features of the interrupt capabilities in the kernel and the GPIO subsystem that implements all that for you in that protocol driver, okay? Put those two together. So, I'd seen in using SPI Dev that you weren't supposed to have it in a compatible string. Is that right? Because it's not a piece of hardware. And with Beaglebone, for example, there was like a patch that then made it complain really loudly and I think we've squelched that. Mark, this is going to be the last question because we're going to run it. But Mark should answer this because the maintainer of the subsystem is here. What was the actual question? Can I? You put it into some file. I guess that's what you're actually supposed to... So, you were showing that instead of having SPI Dev, you're actually supposed to have an actual compatible string for a piece of hardware in which case you're supposed to add it into some file somewhere? Yeah. Yeah, the SPI Dev has a list of compatible strings. So, you're supposed to put it in SPI Dev. Maybe like a C store. Yeah. So, yeah, just say SPI Dev is how we handle it on Linux or write a driver for it. So, why was SPI Dev removed from the compatible strings? Because, like Matt said, SPI Dev isn't describing the hardware. It's describing how you want to drive it on Linux right this very minute. So, we now complain loudly about it to make you actually describe your hardware because somebody might come along later and write a driver for it and you have no idea what it is. And even when you're using... Even when you were using SPI Dev, it's not very helpful for user space to work at which particular thing to do with that SPI Dev if we just say SPI Dev. So, you couldn't write a generic driver or generic SPI Dev using user space driver.


Took me that long to remember the lyrics. The tempo, where did that go?  No intelligent commentary here. Never.  Always. So I need to grab Twitter for juicy content. It's so juicy. Patreon. Thank you so much. You're why we're coming to India. Yeah. And thank you all on Twitter as well. Thank you for supporting us there. Which in case you were wondering, for those of you who've been around a while, yes. There is still pole dancing. Lot of it. Naked. Ring the bell if you have a notification squad. Anyways, today we reacted to a trailer. This is the sequel to one we've already reacted to. A trailer sequel? Whoa. No. Yes. This is a Tarabin Laden. Dead or Alive. So this is the sequel to Tarabin Laden, which we saw the trailer for. Right. Yeah, I was having a deja vu moment there, because I remember Tarabin Laden. This is Tarabin Laden, Dead or Alive. Dead or Alive. Okay, I want to read the... This was funny, was it not? Yeah, it's like a satire. Right, a satire. Basically. Tarabin Laden, Dead or Alive. Translated without you, Ben Laden, Dead or Alive. There's a 2016 Indian comedy film written and directed by Abhishek Sharma. This is a sequel to the 2010 film, Tarabin Laden. The sequel, however, isn't as good as the prequel. In this movie, the character of David is played by Sekhendra Kair. Anupam Kair's stepson, Anupam Kair, played the doctor in Silver Lining's playbook. Oh, cool. I do hear, though, that the trailer... Because the first one didn't have a very good trailer from what I read. But, looks like... I hear the second one has a better trailer. A better trailer, but the prequel is a better film. I guess. Okay, according to who? Will be the judge of that. Here we go. Okay. My fellow Americans, US forces have finally located in once-and-for-all Iraq, Osama bin Laden. Mr. President, do you have any proof that he is dead? In America, Sadduabha, Karbali had dreamed of poverty. He moved on. And we have built the home of Afghanistan. David Laden, do the chart. And... I'll cut it. Who's going to do it? I'll cut it. Let's do this cut. They got me. The guy used to look exactly like Osama. Mr. President, I'm going to get you.  That's the person for David Chutah. Hollywood producer. We're going to make a film with you. What are we going to do? We're going to die. Okay. Then put him in a chopper flyer. And throw him in the sea. And black out. We'll be shooting as tragically as possible. But it's a clean night. Thunder. Thunder. Cut too. Our helicopter has reached its destination. We're going to get you. You're dead. I'll get you. You're dead. So, Sai Bhangmeen, you see, he's taking the loot from here.  All right. Our branch is not here. I've given you a reward. I'm going to get Osama bin Laden. Osama, Osama. Osama is saying that he's alive. I'm going to give you a good news. In the name of Allah, I'll give you a donation. I'm going to give you a donation. I'm going to give you a donation. Thank you. Thank you. Thank you. Osama, it's time. Yes. Who put it? Who put it? I think I've put it down. Whoa. I can't tell. If it's utter trash. Yeah. Yeah.  Yeah, I know. It looks like it could go either way. Yeah. Also, it looks like it might lean more toward train wreck. Yeah. I don't know. You're going to have to let us know on that one because that was, I'm all for satire. Oh. Like make fun of Hitler, make fun of who, I don't care who, obviously. But it's like, it has to be good. Right. Yeah. It has to be good or it's just going to look just. It'll be bad. It'll be terrible. Pretty simple here. Like when Jojo Rabbit was, you know, making fun of Hitler. Brilliant. It's a brilliant film because it was done really, really well. Yes. And correctly. They make fun of Nazis. As is as much as, as much as sometimes I am so deeply offended by him and don't appreciate some of his tactics. Sasha. Sasha, man. Yeah. He's, he's just, he's gold. Yeah. So funny. But yeah, yeah. So you're going to have to let us know if either of them are worth watching because I can't remember. I believe from what I remember, I think you guys said one of them is better than the other. That's what I remember.  The prequels better than the sequel. But that did, that was definitely the Obama. And it is a fun, the idea, and I think this is the concept. I like the concept of the fact that maybe the entire assassination was a Hollywood film. It was a, like they never really got him and they just made everybody believe that they got him. Yeah. I like that idea. And they hire an actor to be Osama to make it look good and make it look like they did it. This guy apparently gets a lot of work as Obama. Yeah. Cause that I'm pretty sure it's the same guy. Hey, this guy's in it. Was he? Yeah. What was he? I don't know. I don't know what to say, isn't he? So they know what we're talking about. We're talking about Pius Mistra who's a singer and a, where's he? Anyway, where's he at? I don't know. Trying to find the actor. Prison Obama. Cause I believe he's, he's an American actor. But I'm wondering if he just gets a lot of work as Obama. Which I don't remember, what did I say about him? He, he didn't look like Obama. You sounded like him. Okay. Yeah. So they just got a guy who sounded like him, but looked absolutely nothing like him. Right. Barack Obama. Yeah. If you have to go for what you want to, yeah, I guess you would, you'd go for more for the, the sound and maybe get close to the mannerisms versus if they look like him, but don't sound like him. I guess it depends on what type of film you're making. Yeah. I guess in the satire, you should go for sounding so people understand that. Yeah. That's what you're trying? I'm, I'm guessing this is not good. You'll have to let us know. That's my guess. Cause we have no way of knowing that. But let us know that in the comments section below.


Hey everyone, welcome back to Nintendo Prime, and you are watching our Prime 5, where we give you five big Nintendo stories from the last 24 hours. We actually only have four of them today, but some of these stories are really huge, including some really big game sales I don't want you to miss out on. Like, yeah, maybe you wanna wait till Black Friday, Cyber Monday, and all that here if you're in the United States, but I'm telling you right now, the sales we're gonna talk about today are some can't miss goodness. That being said, if you enjoyed the video, be sure to drop a like, subscribe to the channel, and let's get into the news. And our first batch of sales today for our first story comes from Amazon, who is running an early October sale for all of you guys out there, looking to either buy a Switch or buy Switch games, digital or physical. So let's get into the game list, shall we? So we have Nintendo Switch Sports selling for $39.99. We have Super Mario 3D World, plus Bowser's Fury selling for $39.99. We have the Legend of Zelda, Skyward Sword HD on sale for $39.99. We have Animal Crossing, New Horizons, plus Happy Home Paradise DLC for $59.99. Hyrule Warriors, Age of Calamity is $39.99. Yoshi's Crafted World is $39.99. New Pokemon Snap is $39.99. Life is Strange, True Colors is $29.99. Neo, The World Ends With You is on sale for $24.99. The Ninja Saviors, Return of the Warriors is $29.55. Hunting Simulator is on sale for $24.80. Two Point Hospital is on sale for $21.99. Clubhouse Games, $51. Worldwide Classics is on sale for $29.99. And Wonder Boy Collection for $21.99. Now these are physical games, let's get into the digital sales they have on Amazon right now. The Legend of Zelda, Skyward Sword HD for $39.99. Super Mario 3D World, plus Bowser's Fury for $39.99. Hyrule Warriors, Age of Calamity for $39.99. Yoshi's Crafted World, New Pokemon Snap, both of those are $39.99. Super Mario Odyssey, plus Mario Kart 8 Deluxe, a combo pack for $74.99. And then another combo pack of Splatoon 3, plus Kirby and the Forgotten Land for $99.99. Now they also have some accessories on sale as well. Nintendo Switch Joy-Cons are on sale for $71.99. The Nintendo Amiibo, Zelda and Lofwing is on sale for $14.99. The Nintendo Amiibo, Steve plus Alex two-pack is on sale for $26.99. The Hori Nintendo Switch Split Pad Pro is on sale for $44.99. The Tempered Glass Screen Protector for Switch OLED is on sale for $6.49. Nintendo Switch Carrying Case and Screen Protector Splatoon 3 Edition is on sale for $22.49. And the Nintendo Switch 512 Gigabyte Micro SDXC card is on sale for $67.99. I'm gonna try to have a link to all of these sales down below. There'll be Amazon affiliate links if you guys wanna help support the channel by any of this stuff. Obviously we're getting to the sales season. We have more sales to talk about before the Nintendo Switch eShop later in the video. And our next story deals with Viola and some new footage from Game Informer for Bayonetta 3 which I remember releases on October 28th. Viola apparently is slightly slower than Bayonetta and has a more deliberate style of attacking than she does. She also has a special demon friend named Cheshire who she can send out in battle and a completely different way of triggering which time. Obviously just check out the video for more information if you want, I'll put a link to the full video down in our source section in the description. And yeah, you can see what makes her absolutely unique. Remember Bayonetta 3 releases on October 28th. Some live streamers in Japan are doing some really weird things with Splatoon 3. It's not that they're just streaming Splatoon 3, they are literally taking the ink and making it vanish so they can play adult videos behind their live streams. And Nintendo is not happy about it. They issued the following warning on their Nintendo of Japan Twitter account. Use that violates public order and morals act that intentionally misled the rules of the game, acts that significantly damage the value of the game or characters and the world and acts that encourage or take advantage of them will be deleted or legally enforced. We may take other measures. Please be careful. Now this is through a Google translate so that's why it sounds a little weird. Essentially Nintendo of Japan is DMCA claiming all the videos and live streams that are doing this. Obviously Nintendo does not want Splatoon 3 associated with adult content and people green screening out the ink colors and showing, that's just not gonna fly for Nintendo. And obviously in most streaming platforms streaming adult content in general is already against the law. So hey, they thought they were clever. The hashtag surrounding it actually started trending on Twitter. That's how Nintendo caught wind. And yeah, they're not letting that happen anymore. It's kind of sad that Nintendo has to deal with stuff like that, but everyone's always trying to make a quick buck, I suppose, and I guess these streams were clearly getting a lot of attention. And our last story for today deals with Ubisoft who is doing a spooky sale, as they call it. I don't know why there's nothing spooky about it. It's just a Nintendo Switch eShop sale in October but hey, it's spooky because it's Halloween. Yeah, so I don't ask. So the games that I wanna highlight to have on sale, they have Rabbids Party Legends is 40% off and now 23.99. Assassin's Creed at CEO collection is 50% off and now 1999. Stick of Truth, so South Park and the Stick of Truth is now 60% off and at 11.99. South Park and the Fractured Butthole is now 75% off and now at 14.99. Now this game is one I really look forward to. Starlink Battle for Atlas is 80% off and now at 11.99. I don't know why I said look forward to. It's already in my collection in a really great game. And again, I don't know how this is spooky. None of it makes sense to me, but hey, it's Halloween time I suppose coming up and my whole family wants to apparently get the blow up dinosaur costumes and run around like we're from Jurassic Park. I don't know. This is going to be insane and we'll probably record some footage for you guys during our Halloween trek. Anyways, folks, thank you so much for tuning in. I am Nathaniel Rubblejad from the Tenerife. Hopefully you enjoyed this episode of what's basically the prime four today instead of the prime five, but hey, that's cool. Remember to tune into our podcast tonight over at the Nintendo Prime podcast channel. We'll put a link to that podcast episode down below. It's episode 71. It's going to be live at 8 p.m. central time. You guys can come tune in, join, I believe it's me and Eric and then I believe Andrew's restart might be coming on. Maybe the guest will change. I don't know, my goddess, he has to step out for some personal reasons, but anyways, folks, thank you guys and we'll catch you in the next episode.


Anyone new on the design track? Has anyone joined the first session here? Okay, cool. Welcome. It's a cool room. I like to think of it as the decompression space, in case of not going to the other one. So when I talk about psychology of UX and adoption, I'm a psychologist, not a couch type, but I study psychology and interaction design. And when I was doing that, I learned a lot about models, like frameworks of what drives people to adopt new technologies. And in preparing for this talk, like over the last weeks, I've been trying to apply that to our space to see how does it translate all these frameworks. Yeah, so that's what I want to talk to you about, but first, I want to talk to you about porn. And why that's interesting will become a bit more clear. I hope so, later on. This magazine, Time Magazine, in 1992 declared hybrid porn specifically as one of the bigger inventions of the past millennium.  It was a big deal in agriculture, so it was a big deal for food around the world. But it was also a big deal for understanding what makes people adopt new technologies. Side note, but what's interesting, this is 1992, a special fall edition. A lot of the content is sponsored by IBM. There's a lot of talk about network computers. There's no word on predictions of the internet, as we know it now, and all the services that we use on it. Even though this was 1992, so we would expect that to be kind of ubiquitous knowledge already. So the story about porn, we think it's some days here to check.  And then years past, it was released to farmers, and it had a lot of benefits to speak of. So the production rate would go up by 20%. Farmers could move to mechanical ways of production, because the way that porn grew had changed the size or the equal height of the stem, so it made it easier to cultivate. It was also much more resistant to drop. So there were a lot of functional benefits that would make farmers be like, okay, let's all switch to hybrid porn. And then next to that, there was an alliance of farmers that also adopted this technology from the university and started pushing it and promoting it. So there was a lot going for this new type of cultivating porn. One of the downsides, obviously there were downsides, was that farmers would need to buy their seeds every year. So they needed to change something in their behavior compared to what they were accustomed to.  There's a lot of changes happening there. And so they wanted to figure out why, what made some farmers decide to switch to hybrid porn, others not yet, so it was kind of a big deal in that state at the time. So they asked, they sent out a survey to farmers in the state asking, why and when did you switch to this new type of cultivation? And what they found was that within five years, 10% had switched to this new type of production. The three years after that, 40% more people were farmers switched to that new type of production. No Excel yet, but they plotted the data. And then they found this, which if you've looked at, like if you ever Google, it's like technology reduction, you basically always find this S curve. Okay, there's like a first 10%, and then at some point, it kind of grows a little bit more, and then there's this switch, this critical point that we call, like now there's critical mass. And this is what we all strive for, because at this critical mass, we'll get there. That's when mass adoption will happen. And then this is a guy who kind of summarized that research and followed up by doing loads of research after in other fields to understand how does this translate. Is this S curve something that occurs in every new technology that we introduce? His conclusion was yes, like he actually drew up that S curve with some variations of different technologies. Interesting motivation for him to start looking into that was that he always saw his dad as a farmer kind of wait till the last minute when everyone was starting to use something new and his uncle Eddie, another farmer, would already use something new, his dad would wait. And so he's also the guy that kind of coined the terms early adopter after investigating that based on his family story. What he talks about is not necessarily adoption, like the whole concept of adoption is fairly new. What he talks about when he describes like studying new innovations is a diffusion of innovation, which like in his descriptions is slightly different. He actually says diffusion as a paradigm originates a bit more from anthropology because anthropologists look at things from the perspective of humans and they tend to take on that perspective to then blame a system or like credit a system when something good or bad happens, but always from the perspective of users rather than a system. So Everett Rogers defines diffusion as a process by which an innovation, which is one point, is communicated, which is the second. Over time, time is a very critical element according to him and among members of a social system. I started to think that what are then the difference between that type of diffusion and what we now see as adoption and what we talk about so very often of reaching a crypto mass adoption. Some differences if you look at the different models out there are that diffusion usually refers more to a society as a whole whereas adoption is more related to the decision of one specific individual. Diffusion relates to technology, infrastructure, whereas adoption usually relates to a product or service, something built on top of that. In terms of what it does functionally, diffusion relates to something being supportive, not delivering the actual value instantly whereas adoption is interactive, something that brings you value, some effort into it, it's interactive. And diffusion tends to take longer. So in this study, based on a range of different technologies being introduced, it takes about 20 to 30 years whereas adoption, if you think about all the popular web services, they take between five and 10 years. Hybrid porn was a really rapid adoption at the time for new technology, taking around 13 years I believe. And then also there's just a very different stream of research into both, starting with Edward Rogers but then there's this other guy, Earl Mann, who started to investigate adoption more closely. So next to porn, an interesting example is the computer mouse, which is commonly credited as being invented in 1973. Actually it had been around a little bit longer, and it was a really nice post, I may have included the link, I'm not sure, by Bill Buxton, a great guy if you haven't heard of him, look him up, he has a wealth of information about how new technologies grow. He kind of describes the history of the computer mouse that I think is very analogous to how we might be looking at, let's say, Web3 as a new technology. So the mouse credited to be invented in 1973 was actually 1969, and then it still took years and years before it actually reached household adoption. So there were commercially available products, especially by Xerox PARC, but before David's household adoption was in 84, which is pretty much a long time after. The way Bill Buxton describes that difference is that there's actually, before that whole S-curve starts, there's a long nose of the technology being developed where you go through invention, which might happen at multiple points in time by different people. There's a refinement and augmentation phase, and there's the productization where there's actual stuff built on top of the technology. In my mind, we're kind of like in refinement and augmentation, we're not really there yet, and let alone that we are at that place where you can start to think of it as an S-curve. Why the analogy to a computer mouse to me is interesting is because the computer mouse needed an ecosystem, and this is what made it last or take quite long for the technology to be adopted. So it needed this place to use a computer mouse, it needed programs to effectively control a graphical user interface, and it needed all the manufacturing around it that took so long. So looking at these pillars or variables, I would say, that Everett Rogers describes that are required for diffusion of innovation to happen is the innovation itself. It needs to be new and interesting to people, it needs to actually add some value. It also needs communication channels, it needs a network of merchants or people that can sort of sell the technology like the way the farmers have an alliance that would kind of vouch for the hybrid porn to be more effective than the average way of working. So it needs agents is how it describes it. It also needs time, it needs time for people to go through their phases of decision-making so they need to get their knowledge of how this stuff works, they need to have time to decide if it's something for them. They need confirmation that when they start using it it actually works for them. So there's all these stages that people need to go through first. And then there's a social system where it doesn't make much sense for me to have crypto if I can't use it anywhere else. So it definitely needs to have support for people in a closed environment. So let's say the diffusion of innovation but when we then talk about adoption which kind of grew later what can we learn from that work that can apply to us as well? There is several models that nowadays are referred to as adoption models but actually in the early days they were called technology acceptance models mostly because you didn't adopt technology, you accepted it because it was kind of enforced on or forced upon you by an employer. These are, I mean, in themselves, if you like models that might be interesting, there's a bunch of them. What they have in common is basically these two factors. Something needs to be useful or at least perceived as useful and it needs to be easy to use. And especially the first one, it needs to be useful at least from my perspective where I'm standing, I work for status which is very much infrastructure oriented. Useful is something that doesn't necessarily resonate. It's much easier for us to talk about the usability of the applications that we're developing at this point. So we could sort of add those to the model. And then there's obviously a lot of knowledge about UX which is also relatively new. If you kind of look at the process of how UX came to be, initially there was a bit more of a thing called human engineering when Bell Labs wanted to design the rotary phone and they were kind of struggling to decide do the numbers go on the device itself or on the rotary. And they hired someone to test that and to get input from people and they wanted to design it such that it would fit humans and they called it human engineering. Then the personal computer came and the industry started talking about human-computer interaction which to me that emphasis is interesting because it's talking about the computer, the system as a whole at that point in time. But if you look at what happened to the industry after that when web technology started to come up, the emphasis switched more to human interface design so it moved away from the system and kind of moved up to the surface of this is only what you interact with and that's what we'll try and optimize. And then even later, even though the term started to be used in 93, if you look at the actual definitions, user experience happened and that kind of only became popularized when services became more common on the internet. And this is like looking at the definition of user experience, how that kind of shifted over time. There was this concept already, like context abuse from these applications, right? Will something work in a particular factory with given timelines? That was kind of the extent of the usability. Then in 2010 there was a switch and this is only 2010, it's not that long ago. And that user experience was added as in the person's perceptions and responses that result from the use and or anticipated use of the system product or service. These are standards, they're not the most fun read, but it's interesting to see how they change over time. By the way, it kind of looks like context abuse is no longer important. It was just moved to another position in the document so very much they are still. And then another thing that happened in 2010 was that usability kind of got this side note added to it where there was like another emphasis on specified users, the goals, the context abuse referred to a particular combination of users, goals and context abuse for which usability is being considered. This is like reference to context. So last year, and I'm sorry to say that this was already last year, with some folks of status, we went to South Korea for a field research trip where this context became incredibly clear and also it became incredibly clear why we needed to be in the country to understand the context. What we found was obviously there had been a high adoption rate of cryptocurrencies but what we found was that it was especially connected to the housing market, the prices of the housing market, the social pressure for young people to buy a house and then next to that the investment regulation and how difficult it was for young people to find other means of investment than crypto. So this whole context kind of played into why people started to use cryptocurrency, not just to make an extra buck or because it seemed interesting. There was a whole sphere of context around it. And so looking at another model, there's loads of these in psychology. This is also next to Don Orman, one of the followers of UX I would say. There's this continuous reoccurrence of there's something... Sorry guys, that's my time. There's some reoccurrence of something needs to be usable but it also needs to be useful in the first place. And that you see popping up over and over. So one thing that we can add is the importance of context because we see it coming back in all definitions. This is kind of like a side note but a comment by this guy Nielsen that I find interesting is that over time we kind of switched from a you pay first then you experience something to you experience and then you pay with the introduction of service models. This is an interesting thing to keep in mind because we're in a way reverting that.  So from some of the studies that we did there's one more factor that I would kind of add to that model of what are things that are important to at least think of or keep in mind or check to cover our bases if we want something to be adopted. What we found in Iran where we thought privacy is going to be super important because we build a messaging application turned out privacy was, yeah it was important but it wasn't super important people had telegram, it was blogs and that only made it more trustworthy for some reason. What did come back over and over was this it should be common among everyone and my friends should be on there too so this social network and then another one was from I would say three months later when we did this familiar study in Japan and in this study we would ask people about the current messaging applications they use and we would ask to write either a breakup letter or a love letter depending on how they felt about their current application and when kind of looking at what does an application mean we've got through this strategy of write a breakup letter write a love letter make it really apparent we got to things like I could lose so many contacts or I'd be so lonely and kind of explanations for the use of technology and this to me would be reason to like emphasize or add sorry about the collars there this concept of human connection specifically because it's something that we really do not seem to take into account too much as in any transaction I make on the blockchain so far does not allow me to add a note or receiving any value does not allow me to say thank you which is a pretty basic thing in any human interaction and looking at other applications that seems to be one of the defining aspects so that's kind of like the list of factors that I would keep in mind like either looking at like the wider picture of the technology but also at the lower level like do we give people time between switching like trying out an application before they actually have to decide that they'll use it do we allow people to try something without backing up their seed rates so how do we fit into this this concept of decision making do we have enough communication channels or agents in place and there's a bunch of more I kind of see it as a list of triggers like things to think about and that's all I have except for the QR code which I think you know a lot better what to do with that than I do I was just asking about it there thank you a few more coming in thanks for being here my name is Chris Sugg I'm a UX UI designer at Aeroswap and today what I'd love to do is just tell you some stories about user research that we conducted at Aeroswap and specifically some of the challenges of adapting kind of traditional UX research methods to these specific users within Ethereum okay and I guess we're not the bad I also want to say you know this isn't really supposed to be a prescriptive talk per se but more so just sharing a very lean product team's attempt to conduct meaningful research within the space and figure out how to do it well so I hope we can all chat about it afterwards come up to me if you're doing stuff better than we are so off the bat here's the agenda we're going to do why user research because we can't be in a place like this and not advocate for it at large we're going to talk about two kind of buckets of user research and then we're going to focus in on one side and talk about some specific methods that we have dealt with and adapted alright so why user research the goal here is not just to build good products but it's to build the right product and when I say the right product I mean a product that is for the end user and I think this quote by IVM puts it well user research focuses on understanding user expectations behaviors needs and motivations through methodical investigative approaches insights are then used to ensure that all product design decisions do benefit the user and I think this is something for this space that we need to remember the products we're building are for the user they're not for us as the developers the designers they're for the user in the end and so let's work to get to that end so now let's talk about two kinds of user research if you're a designer or a researcher this may be a 101 kind of situation but we're going to go through it anyway we've got quantitative and qualitative so when we're talking about quantitative research this is evaluative research so these findings will come out in measurable data numerical format some examples of this could be heat mapping so how many times is a user clicking on a button how many times are they missing a field eye-tracking, AB testing, etc we're going to be talking about qualitative today which is more exploratory it sometimes gets to bad rap as sort of the softer of the research sciences but the whole point of qualitative research is to observe behaviors and attitudes the findings are non-numerical some examples here would be interviews field studies and focus groups this is the more sort of personal research it's human connection and understanding sort of core motivations of people as opposed to just numbers so just to give you a little bit of a snapshot the point here is not to say that one of these research sides is better than the other but it's about using them together to get the best research you can get so at AirSwap we use a combination of a ton of tools and this is just a few so on the quantitative side we use a couple products we use hot jar and mix panel this is where we do our heat maps recordings we track our conversion funnels KPIs, daily active users, etc these are the ones that we hear a lot about so qualitative research on the other side we have candy feature requests so our users can free form ask us for features telegram and discord feedback channels so again, sort of a free form avenue for our users to talk to us and then the three that we're going to kind of live in for the rest of our time together are surveys, field studies and user interviews so qualitative research we need it Ethereum needs it and the reason we need it is this kind of research is what takes us out of our context and shows us what our users really need so it takes us out of being developers, industry insiders designers that love Ethereum and puts us in the spot of our users to understand what they really need for products but qualitative research is hard in Ethereum and we're going to talk about why and I think the crux of the thing is basically this our users go by wallet addresses and not names so what I mean by this you can imagine on a traditional platform if I'm signing up for Pinterest I'm signing up with my name my email address probably my date of birth if I'm doing that I may have even checked subscribe to email list while I did that and then on top of it maybe they have social media presence that I'm following with an identity attached to it so in normal web 2 consumer web there is identity that is fundamentally connected to the product so when you're looking at doing recruitment or conducting research there are pretty easy avenues to get to those people to find them to know who's using it for us on the other hand we have wallet addresses and for our users this is one of the biggest value propositions of the entire thing their anonymity, their security is huge and we care about that but how do we conduct research when that's the case and it really goes into everything who even are our users where can we find them and then if we can figure out who they are if we can figure out where to find them how can we actually get to know them again in this true sort of human way get to know their needs so we're going to start with who are our users and we're going to talk about UX surveys so when we're talking about fundamental UX surveys in traditional world the goal of a survey is to gather both quantitative and qualitative insights from a lot of users at once so this is a research method that doesn't cost a lot you can send it out to a huge distribution channel a subscription list you can send it to a company and they can do it for you you can then extract trends and understand all kinds of things from a lot of people the second way this is used would be like a screener survey for recruiting users for future research so for us this piece was really interesting we were interested in the first of course but we want to recruit users we want to find these people I personally wanted to bring them into the office we'll talk about that later but so here's what we found the distribution piece was hard and we've done these are just two snapshots of a couple surveys but we've done a ton so when we were first doing a survey we were like okay let's get it to a ton of people and so we thought maybe Craigslist maybe we could put together a survey that would really weed out the real crypto people the real Ethereum people and we got a fair number of responses we got like 80 responses and we actually did bring three people into the office which was a total shit show but and it was interesting they did give us insight but what we realized is that it wasn't quite spot on enough that this distribution channel it wasn't quite representative of the kinds of people that were using our products they needed to be more savvy so then we were like alright this was too broad let's make it smaller let's not expect as many respondents but let's expect some quality so then we went to Telegram we distributed there you can see for this survey we had 11 responses which you know that's not a ton but the thing with these responses is that they were excellent super high quality responses we had people responding in paragraphs and paragraphs about their experiences they were willing to answer all of the questions and it was great but as far as recruiting them for future research they were not in of those 11 respondents responded with their Telegram handles none of which responded when I reached out to them so we realized that our users are absolutely willing to give rich responses to these open-ended questions as well as closed-ended questions in survey form but they still want to remain anonymous and so here we were like alright we got something from it so there you go we're not going to get those things from you at least not right now so where are our users let's talk about adapting UX field studies for a second the goal of field studies is to observe users in their natural environment and to situate oneself as the researcher in user-specific contexts so coming into the Ethereum ecosystem I come from working with internet stuff and consumer tech and when I think of field studies I think of doing a field study for REI going into an REI store for four hours and watching consumers look at the sunglasses look at sweaters this is not like that there's nowhere I can go to find Ethereum users to watch them do their daily things but just because we can't do it in person does not mean that we can't see what people are doing so this is an example of what I'm going to call a field study this is a screenshot from Telegram we were building a product for OTC traders and so this is a trading chat room and what's really interesting here there's a little bit of gibberish WTS hashtag axle 1900 0.1 ETH translates to want to sell 1900 axle at price 0.1 ETH so what's interesting here we were trying to figure out how to create a really intuitive order builder for OTC trades so the main inputs on this thing are selecting a token and amount to send and then selecting a token and amount to receive but what was so interesting here is that the syntax that these traders are using is not sell 1900 axle and receive 190 ETH which was represented in a lot of the products that were already on the market and so what we got to do is implement a price field which for us was a huge differentiator from what was already out there and we heard from our traders very actively that this really helps their workflow that they're thinking about what they're going to send and a price not just what they're sending and receiving so this is one example of how we sort of adapted field studies and applied it so now let's talk about UX interviews we want to get to know them and traditionally UX interviews are all about an informal setting to really get to know someone to get beneath what they think they want and to get at what they really want so you're trying to uncover user motivations, feelings, needs and pain points and it's very personal it's about putting a face to the person using it now this is hard like I said we had some people come in but again they weren't quite representative of the users that we really wanted to be building for and there are a few challenges with the users that we're really trying to build for which is that they are global they're everywhere, they're not going to come into our New York office and they don't exactly want their face to be seen so while we may not be able to see them we can work to create analogous research environments over chat and through forums so what I did was cold message people on telegram and said hi I'm Chris I'd love to just talk to you about OTC and a number of people were incredibly generous and really did talk to me and you know I don't have their name but I was still able to get to a point where I started to understand who they were and what they needed some other ways that we have approached this so that's sort of the individual connection piece to actively foster community around our products and so we do face product releases on our most recent one we start with a closed beta and this is paired with a telegram or discord channel that we've had people sign up for who then have conversation give us active feedback we implement that feedback we do a public beta we invite people into another channel and so just creating a space where we can still get this informal sort of human feedback on the things that we're doing so in the end we may not have a name and I think that what I have learned is that we don't necessarily need a name because we can still get to know our users through creatively thinking about the kinds of ways that they are interacting with the world and the way that they're interacting with one another so that's pretty much it but I would I mean for those of you in the room I don't know is anyone like a UX researcher or has conducted UX research okay yeah tell me what you do later because it's tough it's tough but it's good thank you yeah so we had to review the first I came and I was actually out on the sidewalk having a cigarette and he came up to me and he was clearly drunk like actually drunk and I was like oh geez and I was like running away and he was like oh is this air swap and I was like oh yeah this is air swap and he was like oh I'm here for the user interviews and I was like come on down we had dark web criminal and the third guy was like absolutely useless like I think he just wanted the gift card I mean there were insights to be had as far as just you know the consumer side these were definitely kind of like edge case people that were not exactly our people we were able to get something from it but yeah that was yeah oh well okay yes Google Analytics yes well if you use it I tried it with my team and they some of them objected it so we ended up not using it and I wonder what you are doing I don't think we're using Google Analytics oh we are we use it and but the fact that it's not the actual and that's the reason did you have a question yeah I mean you mentioned that the gift card so I was wondering about like incentives the other thing is like some of this stuff is new to me but you know like people raise the uniform badges to identify the litter bear to try to do anything creative around like badges and ballads to recruit people well we did think about these kind of things and we used a gift card for this particular session and I think that was quite applicable in the door but at the end of the day like the people that we want to be talking about we don't are talking to rather I don't think that necessarily luring them into the door are the people that we're trying to talk to like you know what we found on the surveys is like these people want to give feedback we all want to contribute to making it better it's just a matter of figuring out how to connect to them and find them so what are you doing like industry-wide studies is there any like somebody must be you're doing a label too there are I'll say yeah the Ripple team is doing the UX pattern in general it's a design system we've done a bunch of those and we are doing now on the industry or layer 2 there's a talk here tomorrow on that layer 2 design pattern how are you connecting with the users not actually users but like like a lot of product people are looking for aggregating and to understand what the connections are so like how do we obviously like these individuals companies have relatively small budgets but you know we need deep research from like that yeah it's it's very special if you want we can no no it's fine this is the the best this is the room for the talk so in terms like are you able to identify contact them directly or not so I think that what we found is you know telegram handles are sometimes the extent of the identification but then there are also of course those users that we do have actual relationships with that we know a name of or at least a first name but I think that in my head most of them are their telegram handles yeah yeah yeah yeah and of course we've done that I think that the idea because I think this is always kind of attention here is like do we just try to build for the people that are using it or are we trying to get you know at least a degree further towards a new user or you know so I think that represents also that goal so can you talk a bit about if any learning came from the quantitative side did you learn something interesting just about the users in general yeah or I don't know you design something and you discover something wasn't working somehow I think well what was fun was talking to some of our users and actually sending them designs so there are a few that we're pretty close with now that I've actually sent like active prototypes to and they have like mocked them up and added comments and you know we take it with great assault but it's been fun to see them sort of actively engage with what we're doing and from mixed panel and from that oh the quantitative side I think those and again it being evaluative it showed us like for example on our decks our instant experience like we noticed that people were missing they were clicking something that wasn't supposed to be clicked and they were missing the thing that was supposed to be clicked and it's that thing that you have to see that really improves it so yeah is there resistance to like things like segment and tracking data like if people freak out I don't know if they freak out but I think that in general we can say like ideologically in this space people don't want their data to be tracked or held but I'm not saying from personal experience I've come up against someone you know up and down and add something to that so not my previous company but a company I worked before we had a lot of users and we saw a drop of basically from 170% people actually blocking things like segment privacy measures so that meant that we were missing a lot of traffic because of that and then on top of that because we're European and we had the GDPR which meant we saw another drop of 40% so in the end we looked at other traffic we were really worried that our traffic was actually going down because of the time span of the year it was dropped by almost 50% but then actually looking at profit and other things that was pretty good so we saw this big mismatch between what our data was telling us and then what the reality was happening on our platform so then we went back to server side tracking and we wrote our own plugins to basically circumvent a lot of the tracking that was blocked so and then we made a combination of those to actually see what is actually going on so that we can make better decisions again because at first it was really scary to see all these drops while these drops were only from people blocking it or not allowing us to track those so yeah so I think that was for us a very good insight to realize that you think differently so that's one and the other thing is that from a statistical point of view it's very difficult if you have a small set of data to actually make something that you can drop conclusions from and I see a lot of smaller startups actually really trying to do analytics and things like this which is really not that useful but you have a lot of traffic so yeah so then things like Altjar recording sessions and looking into this that's very useful but also realize that the platform like Altjar is also doing the same so it's not recording every session trying to think okay this is something significant and then they're awesome


There's a draw. Nice pull-through for Patterson. Two on one situation. Patterson's got Cook if he wants to use him. He goes alone! Does he celebrate away from not use Cook to his left? He went alone. And that's why he was brought into this football club, to break down the lines, to break into the penalty area, and to find the goals from midfield. 57 minutes gone. Bradford City 2, Colchester 1. And listen, listen to that city roll once more.