| 00:01.56 | *** join/#qi-hardware wildlander (~wildlande@unaffiliated/wildlander) |
| 00:06.37 | *** join/#qi-hardware wildlander (~wildlande@unaffiliated/wildlander) |
| 01:12.39 | *** join/#qi-hardware uwe_android__ (~uwe_andro@static.173.76.9.176.clients.your-server.de) |
| 01:12.40 | *** join/#qi-hardware whitequark (~whitequar@uruz.whitequark.org) |
| 01:12.41 | *** join/#qi-hardware kanzure (~kanzure@unaffiliated/kanzure) |
| 01:23.45 | *** join/#qi-hardware dcht00 (~quassel@2a01:4a0:3::5096:aeb) |
| 01:23.50 | *** join/#qi-hardware fdcx_ (357@ceata/consiliu/FDCX) |
| 01:24.01 | *** join/#qi-hardware paulburton (paulburton@gateway/shell/firrre/x-drzcltcwptmjrdvc) |
| 05:12.59 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 06:41.55 | *** join/#qi-hardware eintopf (~eintopf@unaffiliated/eintopf) |
| 09:42.55 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 10:02.24 | wpwrak | whitequark: btw, are misssing letters in the text screen a known issue ? i'm using commit 7dbbd75: |
| 10:02.27 | wpwrak | http://downloads.qi-hardware.com/people/werner/tmp/ss-bad-text.png |
| 11:16.22 | DocScrutinizer05 | ooh I thought it's Portuguese. ;-) Seems mostly "b" is missing, then a "V" and a "F" |
| 11:51.25 | wpwrak | yeah, it looks almost as if it meant something ;-) |
| 13:20.16 | planasb | my blog http://www.embedded.lt .. how to become hw hacker ? |
| 13:34.23 | wpwrak | whitequark: in platform/gtkmain.cpp:TextWindowGtk:TextWindowGtk, added const char *display_tw = getenv("DISPLAY_TW"); set_screen(Gdk::Display::open(display_tw)->get_default_screen()); |
| 13:34.29 | wpwrak | alas, no observable effect :( |
| 13:36.01 | wpwrak | (that is, unless i put garbage into DISPLAY_TW, which produces "Unable to init server [...]" followed by a segfault. the latter since i don't check the success of Gdk::Display::open) |
| 14:49.15 | *** join/#qi-hardware sandeepkr (~Sandeepkr@103.49.155.114) |
| 14:55.17 | *** join/#qi-hardware dandon (~dandon@185.16.52.24) |
| 15:39.48 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 17:01.08 | whitequark | wpwrak: yeah bug #151 |
| 17:01.37 | whitequark | as for DISPLAY_TW, hmm... not sure |
| 17:16.09 | *** join/#qi-hardware r3dux (~r3dux@114-198-30-198.dyn.iinet.net.au) |
| 17:16.59 | r3dux | Hi there, would I be able to ask any of you a question about SR-latches or D-latches (i.e. mechanisms for storing state)? |
| 17:17.19 | larsc | well, you can always ask |
| 17:17.43 | r3dux | Okay, will do! =D |
| 17:19.30 | r3dux | I've been reading about SR-latches - and they're quite simply two NOR gates cross-linked which can save state, which is the basis of all memory. |
| 17:20.33 | r3dux | After reading this, I thought "I know, I'll implement this in software to make sure it works and that I understand it." - only, it requires simultaneous outputs from both S (signal) and R (reset) NOR gates. |
| 17:20.46 | r3dux | And I don't know how to do that. |
| 17:21.34 | r3dux | I don't think I could even synchronise threads to do this. |
| 17:21.45 | r3dux | Or fake a clock. |
| 17:22.04 | r3dux | I think it has to be a truly synchronous physical operation. |
| 17:22.43 | r3dux | But... I'm merely an inquisitive programmer so I thought I'd ask some higher-powers, which in this case is you. |
| 17:23.02 | DocScrutinizer05 | how about using spice or the like |
| 17:23.25 | r3dux | I can't get to Dune? |
| 17:23.39 | r3dux | Or Arakis, if you prefer. |
| 17:23.56 | DocScrutinizer05 | ~wiki spice_(computer) |
| 17:24.23 | kyak | r3dux: it depends on how you define "simulatenous" |
| 17:24.39 | DocScrutinizer05 | https://en.wikipedia.org/wiki/SPICE |
| 17:24.45 | kyak | if it means "by the end of sample time", than it can be perfectly done in software |
| 17:24.51 | kyak | that's just some logic |
| 17:25.14 | kyak | first calculate Q, than ~Q |
| 17:25.24 | DocScrutinizer05 | I just completely lack the intended purpose of the exercise |
| 17:25.50 | r3dux | Thanks - that's a great suggestion and I'm sure it would work - but I was looking for getting it done without a third-party tool, just in a language |
| 17:26.32 | DocScrutinizer05 | you need to implement a sort of clock, or loop runs |
| 17:26.34 | r3dux | DocScrutinizer05, the intended purpose is like inception... it's to go down many levels |
| 17:27.24 | r3dux | kyak, try it. |
| 17:27.27 | kyak | https://www.mathworks.com/help/simulink/ref_extras/srflipflop.html |
| 17:27.33 | kyak | as you can see, it's just a truth table |
| 17:27.41 | kyak | can be done in any language |
| 17:28.06 | r3dux | Again, sir - try it. |
| 17:28.09 | DocScrutinizer05 | well, then let me start with: nowadays basically all memory is so called "dynamic RAM" which does not work with RS-flipflops |
| 17:28.23 | DocScrutinizer05 | but basically with storage/buffer capacitors |
| 17:28.54 | r3dux | So I'm wasting my time? |
| 17:29.11 | kyak | definitely wasting mine... |
| 17:29.32 | DocScrutinizer05 | no idea. I still don't get it what's the pirpose of writing a computer program that simulates one tiny element of that computer |
| 17:29.37 | r3dux | lol - but saying that, you can't implement it. |
| 17:30.11 | r3dux | DocScrutinizer05, to understand the nature of things - that's all. |
| 17:30.20 | DocScrutinizer05 | listen buddy, we can implement that sort of thing in a single bash line. We just don't know why we would do that |
| 17:30.36 | r3dux | I've been working top-down, I want to see how low it goes. |
| 17:30.58 | r3dux | I know you can. |
| 17:31.11 | whitequark | I think what r3dux asks for is reasonable |
| 17:31.33 | whitequark | it's not obvious how to write a logic simulator that properly simulates feedback loops |
| 17:31.49 | whitequark | and I don't like the condescending attitude around here, it is a perfectly valid learning exercise |
| 17:32.09 | DocScrutinizer05 | and my answer was: for any sort of simulation based on discrete numeric algorithms you need a sort of time granularity |
| 17:32.15 | DocScrutinizer05 | aka a clock of sorts |
| 17:32.31 | r3dux | The D-latch incorporates the clock. |
| 17:32.43 | DocScrutinizer05 | no, that's another clock |
| 17:32.45 | whitequark | that's a different meaning of "clock" |
| 17:32.58 | r3dux | oh |
| 17:33.46 | r3dux | learning.com - also, thanks whitequark |
| 17:33.48 | DocScrutinizer05 | you calculate all states otf output signals for N+1 from input at N |
| 17:34.26 | DocScrutinizer05 | N->N+1 is your clock, the smallest observable time unit |
| 17:34.43 | whitequark | what DocScrutinizer05 says. basically, you take a snapshot of the state of every wire, then use it to calculate the next state |
| 17:34.47 | whitequark | then replace the state in one step |
| 17:34.48 | r3dux | Well that's the point isn't it, S = 0, R = 0, Q = previous state |
| 17:35.05 | whitequark | you can assemble a latch from two NOR gates in this way |
| 17:35.14 | whitequark | you don't have to explicitly model it as a latch |
| 17:35.44 | whitequark | you also don't need any threading for this, it can be done in a single threaded way (and really *only* done in a single threaded way if we're taking a single latch) |
| 17:35.53 | DocScrutinizer05 | Q and Q' are outputs and *also* inputs |
| 17:36.27 | r3dux | Yes they are. |
| 17:37.45 | r3dux | whitequark, I don't see how I can implement this in a single-threaded manner. I've tried: calc q, calc notQ using q, re-calc q ---- it's not it. |
| 17:39.51 | DocScrutinizer05 | there is no "e-calc q" thing |
| 17:39.59 | DocScrutinizer05 | re.calc* |
| 17:40.19 | whitequark | r3dux: you'll have to explain your algorithm in more exact terms if you want a specific answer |
| 17:40.28 | whitequark | or a guidance as to what you're doing wrong |
| 17:40.40 | whitequark | can you write some pseudocode? or actual code also works, sure |
| 17:41.29 | r3dux | whitequark - Let me show you a diagram and my code |
| 17:42.15 | DocScrutinizer05 | your system has 4 inputs: Q, Q', R, S. It has two outputs: Qnew, Qnew'. After you calculated Qnew and Qnew', you print the results, then you move Qnew to Q and Qbew' to Q', and restart |
| 17:42.40 | DocScrutinizer05 | this is one cycle N->N+1 |
| 17:42.57 | r3dux | https://commons.wikimedia.org/wiki/File:SR_Flip-flop_Diagram.svg |
| 17:43.18 | DocScrutinizer05 | please, we all know how an RS flipflop is built |
| 17:44.50 | r3dux | http://pastebin.com/B1NTzbsU |
| 17:44.52 | DocScrutinizer05 | anyway looking at that diagram you instantly see my explanation above started with correct assumptions |
| 17:45.48 | r3dux | I don't mean to demean you, I was just completing the process of: 1.) This is what I want. 2.) This is what I have. |
| 17:46.13 | r3dux | I didn't know how an RS flipflop was built until this evening. |
| 17:46.29 | whitequark | r3dux: so your problem is actually not the fact that you can't nor stuff not in sequence |
| 17:47.05 | whitequark | in fact, your srLatch function is very easy to write and I think you can do so; but it cannot be used with the rest of the code. |
| 17:47.08 | r3dux | whitequark, my problem is that my attempts to replicate an RS flipflop in software fail |
| 17:47.08 | whitequark | let me elaborate. |
| 17:47.30 | whitequark | you understand that an SR latch is an element with state, right? |
| 17:47.30 | planasb | r3dux: maybe you try to write true table of srlatch |
| 17:47.42 | DocScrutinizer05 | the 'trick' is to not look at the feedback of Q and Q', and simply strictly calculate "from left to right" until you got the output values right side of Q and Q'. Then you "do the loop" and copy the output states to input (left side) for next iteration |
| 17:48.04 | whitequark | this means that the SR latch at iteration loop=1 must take its initial state from the iteration loop=0 |
| 17:48.22 | *** join/#qi-hardware sandeepkr_ (~Sandeepkr@103.49.155.114) |
| 17:48.29 | whitequark | however, every invocation of srLatch runs on completely new data |
| 17:49.26 | whitequark | so of course, when s[loop]=r[loop]=0 then the latch simply lacks the information to correctly set its outputs |
| 17:49.37 | r3dux | Yup |
| 17:49.39 | planasb | i want to write software to model logic gates and sell it.. |
| 17:50.05 | whitequark | planasb: pretty sure iverilog is cheaper than whatever you can come up with... at $0 |
| 17:50.14 | whitequark | r3dux: so do you have any idea how to fix this? |
| 17:50.29 | planasb | whitequark: for iOS platform |
| 17:50.41 | r3dux | whitequark, with bodges, yes. -1 bodge for sure... |
| 17:50.52 | whitequark | r3dux: that's not a bodge. |
| 17:51.06 | whitequark | that's a fundamental fact of how a latch (any latch, or any flip-flop for that matter) works |
| 17:51.16 | r3dux | smiles |
| 17:51.50 | planasb | r3dux: buy some DDR4 chips |
| 17:51.54 | whitequark | you will have to do that even if you forget about SR latches entirely and just use NOR gates (or whichever you have) in your entire model |
| 17:54.05 | r3dux | planasb, not sure I need any more than 16GB tbh... |
| 17:54.39 | DocScrutinizer05 | r3dux: for calculating step[N] you take the input for Q and Q' from Q[N-1] and notQ[N-1] |
| 17:55.24 | r3dux | DocScrutinizer05, I understand. Thank you for your help. |
| 17:57.05 | DocScrutinizer05 | for "Q[-1]" you define either 0 or 1, as you like. To start with. Of course notQ[-1]=~Q[-1] then |
| 17:57.38 | DocScrutinizer05 | or rather, you should define R[-1]=1 |
| 17:57.55 | DocScrutinizer05 | that is what real hardware does |
| 17:58.29 | r3dux | Things get real at low-level. |
| 17:58.53 | DocScrutinizer05 | when you power up the RS-Latch, the Reset input gets a power-on-reset |
| 18:00.01 | r3dux | When I power up my toaster it gets warm. Industrial design is also very cool. |
| 18:01.27 | r3dux | (would love to know how those machines crack walnuts without there being bits of shell in it also - I can't even do that manually) |
| 18:02.39 | r3dux | <<< off-topic. It was a pleasure to talk with you, and I've learnt a lot. So thank you. |
| 18:02.57 | *** part/#qi-hardware r3dux (~r3dux@114-198-30-198.dyn.iinet.net.au) |
| 18:14.13 | planasb | thanks for pointing icarus verilog |
| 18:35.07 | *** join/#qi-hardware eintopf_ (~eintopf@unaffiliated/eintopf) |
| 19:00.43 | *** join/#qi-hardware sb0 (~lekernel@201.103.3.197) |
| 19:08.20 | *** join/#qi-hardware pcercuei (~pcercuei@92.177.36.45) |
| 19:24.54 | DocScrutinizer05 | for really help him out of this problem (oscillating? most likely) we had needed to start with propagation delay and then even have a short dive into analog aspects of digital circuits |
| 19:25.42 | DocScrutinizer05 | I guess with POR (s)he's fine off, for a start |
| 19:35.10 | wpwrak | whitequark going through the tutorial videos ... tutorial #2 https://www.youtube.com/watch?v=13qKQ9BHXCM has a lot of repetition. can't one just reuse a sketch for each side ? |
| 19:37.19 | DocScrutinizer05 | also maybe silego GreenPak designer would be sth for r3d2<-ux: R,S,Q->Q: 1,x,x->0; 0,0,Q->Q; 0,1,x->1. :-D |
| 19:38.58 | DocScrutinizer05 | with a single 3LUT |
| 19:40.43 | wpwrak | oh, and regarding sending the text window elsewhere, if i remove TW->set_transient_for(*GW); the window briefly opens on the other screen, then closes. if i keep on opening/closing it with Tab, it eventually stays there. seems to be some sort of race. |
| 19:42.24 | wpwrak | however, when moving the mouse cursor over the text window (if TW->set_transient_for was not called, no matter on which screen it is), cause it to fail with Gdk:ERROR:/build/gtk+3.0-VoKwSM/gtk+3.0-3.20.9/./gdk/gdkwindow.c:6153:gdk_window_set_cursor_internal: assertion failed: (!cursor || gdk_window_get_display (window) == gdk_cursor_get_display (cursor)) |
| 19:42.28 | DocScrutinizer05 | or create a !RS latch from just two discrete components: resistor and thyristor ;-) |
| 19:42.59 | wpwrak | called from gdkwin->set_cursor in TextWidget:set_cursor_hand |
| 19:47.50 | wpwrak | commenting out that call to set_cursor does seem to avoid the crash |
| 19:47.55 | wpwrak | so we're getting closer :) |
| 19:49.21 | wpwrak | also, once i got the window to become stable, it seems to come up without a fuss on subsequent invocations. not sure if it's solvespace remembering something that contributes to the success (i see that it remembers window positions and such), or if it's the window manager remembering it |
| 20:59.06 | whitequark | wpwrak: set_transient_for not working is expected |
| 20:59.56 | whitequark | wpwrak: as for gdk::cursor::create... |
| 21:00.13 | wpwrak | yeah, the latter was the bad surprise :) |
| 21:00.22 | whitequark | wpwrak: https://developer.gnome.org/gtkmm/stable/classGdk_1_1Cursor.html#a73311ad0d1f0b409090decce724023e3 |
| 21:00.25 | whitequark | use this overload |
| 21:00.33 | whitequark | just get the TW screen from it |
| 21:08.09 | wpwrak | this bringe me to the issue of what a Glib::RefPtr<Gtk::Display> really is, how one gets anything done with it without the compiler complaining, and why on earth gtkmm needs to introduce some pointer concept that isn't just a pointer ... |
| 21:08.40 | whitequark | Glib::RefPtr is more or less the same thing as std::shared_ptr if you know what that is |
| 21:08.41 | wpwrak | i.e., i tried to store the result of gdk_display_open so that i could check it for MULL, but even that seems hopeless :( |
| 21:09.00 | wpwrak | nyet :) |
| 21:09.09 | whitequark | define hopeless |
| 21:09.23 | whitequark | Glib::RefPtr<T> can be used in the same way as T* |
| 21:09.31 | wpwrak | C has beautiful pointers, and they're all very standard :) |
| 21:09.34 | whitequark | you can do x->foo() and you can check if(x != NULL) |
| 21:09.43 | whitequark | and they don't do the reference counting for you. |
| 21:09.49 | whitequark | thanks, but no. |
| 21:10.01 | whitequark | gtk has many awful decisions but this one makes a lot of sense |
| 21:10.31 | wpwrak | hopeless = none of the syntax variations i tried when using it to get_default_screen seemed acceptable to the compiler |
| 21:10.40 | whitequark | get_default_screen? |
| 21:10.54 | whitequark | you're using Gdk::Display::get_default_screen() right? |
| 21:11.01 | whitequark | can you show me specific code and the error? |
| 21:11.32 | wpwrak | turning Gdk::Display::open(display_tw)->get_default_screen() into {whatever} dpy = ... ; ...dpy...gdk_display_get_default_screen... |
| 21:11.58 | wpwrak | err, no ... |
| 21:12.17 | whitequark | Glib::RefPtr<Gdk::Display> dpy = Gdk::Display::open(display_tw); |
| 21:12.21 | wpwrak | that was already a form that didn't work. the one that does work is Gdk::Display::open(display_tw)->get_default_screen() |
| 21:12.21 | whitequark | dpy->get_default_screen() |
| 21:12.24 | whitequark | this will work |
| 21:12.50 | whitequark | also you can use "auto dpy = Gdk::Display::open(display_tw);" in a pinch but I personally prefer to write it out explicitly in C++ |
| 21:16.30 | wpwrak | kewl. that did the trick. thanks ! |
| 21:16.53 | wpwrak | now errors to open the display are just ignored, not crashed upon :) |
| 21:28.33 | DocScrutinizer05 | idly wonders how you'd generically catch exceptions in C programs. Except of the very obvious coredump and postmortem debug |
| 21:32.26 | whitequark | DocScrutinizer05: not really any nicely portable way |
| 21:32.40 | whitequark | POSIX doesn't even let you return from SIGSEGV! |
| 21:32.46 | DocScrutinizer05 | oooh "portable" - yeah for sure not |
| 21:32.51 | DocScrutinizer05 | man 7 signal |
| 21:32.54 | wpwrak | setjmp/longjmp is a common approximaition of "exceptions" |
| 21:32.56 | whitequark | I am aware |
| 21:33.02 | DocScrutinizer05 | sure? |
| 21:33.08 | whitequark | it's not legal according to POSIX to siglongjmp out of a SIGSEGV handler |
| 21:33.13 | whitequark | it works on basically every OS out there |
| 21:33.18 | whitequark | but not legal according to POSIX anyway |
| 21:33.20 | whitequark | shrugs |
| 21:34.07 | wpwrak | whitequark: ah, i guess it depends on the definition of "exceptions" :) a segfault pretty much means that you're screwed |
| 21:34.35 | DocScrutinizer05 | "SIGSEGV 11 Core Invalid memory reference " -- but "The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored." so I assumed the others could get intercepted |
| 21:34.58 | whitequark | DocScrutinizer05: you can intercept it |
| 21:35.11 | DocScrutinizer05 | oooh, but not return from handler |
| 21:35.12 | whitequark | but you cannot jump out of it or return from it (according to POSIX but not in practice) |
| 21:35.15 | whitequark | yep |
| 21:35.30 | whitequark | in reality this works fairly nicely for "userspace virtual memory" schemes |
| 21:35.32 | DocScrutinizer05 | that's ROTFL |
| 21:35.49 | wpwrak | whitequark: now ... i'm trying to pass the display i get in TextWindowGtk to the outside world. for deciding on whether i should TW->set_transient_for but also the for the cursor. alas, i can't seem to find a way to get at that TextWindowGtk object |
| 21:35.54 | whitequark | I think some ass-backwards architecture doesn't let you catch a SEGV precisely |
| 21:35.58 | whitequark | it miiight have been Alpha? |
| 21:36.01 | DocScrutinizer05 | however you wouldn't need to return, after all you don't want to resume |
| 21:36.09 | whitequark | depends |
| 21:36.21 | whitequark | let's say I am managing my own file mappings for some reason |
| 21:36.31 | whitequark | then a SEGV is a perfectly fine thing to catch and return from |
| 21:36.31 | DocScrutinizer05 | what you really want is a proper diagnostic output to STDERR |
| 21:36.39 | DocScrutinizer05 | then coredump |
| 21:37.06 | whitequark | there's backtrace(3)... but not standardized |
| 21:37.15 | wpwrak | i'm not even sure what that that parent class of TextWindow is ... https://github.com/ericjang/glsl-playground/blob/master/glwidget.h ? (but there, the reset() doesn't seem to take arguments) |
| 21:37.26 | wpwrak | oh, wait ... you're defining that one yourself |
| 21:37.36 | whitequark | TW is another of those pointers |
| 21:38.00 | whitequark | although this one is C++'s std::unique_ptr for a reason I do not recall |
| 21:38.14 | whitequark | just do TW->fn() for whatever you want to call |
| 21:39.29 | wpwrak | gtkmm really is the height of perversion. gtk was made to have a nice graphic library without all the senseless struggle and bloodshed of c++, and then they brought all that right back in :( |
| 21:39.42 | whitequark | no. gtkmm makes gtk barely usable |
| 21:40.20 | whitequark | as opposed to just being totally unusable, that is. |
| 21:40.57 | wpwrak | i can call things on TW. but how do i get the TextWindowGtk that's somewhere hidden in there ? and as TextWindowGtk not as some other vaguely related class ? |
| 21:41.22 | whitequark | TW->get() |
| 21:41.25 | whitequark | erm, TW.get() |
| 21:42.27 | wpwrak | yes ! thanks ! :) |
| 21:43.30 | pcercuei | are there still people with nanonotes? |
| 21:43.56 | pcercuei | I'd like to know if suspend/resume still works on 4.9 or 4.10 |
| 21:44.38 | wpwrak | whoa ! fun storm coming |
| 21:50.47 | wpwrak | hmm. get() is not available in TextWidget::set_cursor_hand ? |
| 21:53.40 | wpwrak | i.e., the "get" i used successfully to get the TextWindowGtk in TW->get() |
| 21:58.02 | DocScrutinizer05 | whitequark: when backtrace fails epically, would it nuke the computer? ;-) or 'even worse' the program could maybe SEGFAULT and COREDUMP ;-P |
| 21:59.31 | DocScrutinizer05 | I'm proolly as fuzzy and ambiguous as usual - what I want to say is: it doesn't matter if the process segfaults right away or segfaults in a segfault handler while trying in vain to backtrace() |
| 22:10.40 | DocScrutinizer05 | worst thing you trade in (aka pay) for using the backtrace(3) is an #ifdef to make the shite compile on platforms that never heard of backtrace() |
| 22:13.42 | DocScrutinizer05 | and prolly there are smarter more nifty ways to deal with that, like "unresoved external symbol" that nevertheless doesn'T stop the process from starting normally and would just cause a segfault^2 when the unresolved function call actually gets called... which is no probkem at all as I explained above. I'm not the wizard to handle linker and whatnot in such a way to make that fly, I'm also sure there are even better methods than |
| 22:13.44 | DocScrutinizer05 | this crude one I just made up |
| 22:30.03 | *** join/#qi-hardware paul_boddie (~paul_bodd@host-37-191-212-251.lynet.no) |
| 22:30.53 | paul_boddie | pcercuei: Great timing! Was just about to test something on the Ben. |
| 22:31.32 | paul_boddie | I did try a fairly recent kernel when that new guy was setting up his purchase from IDA Systems a month or so ago, perhaps. |
| 22:31.55 | paul_boddie | Not sure if I ever used suspend/resume on the Ben, though. |
| 22:32.26 | paul_boddie | whitequark: I think MIPS has some oddness around exceptions that might prevent recovery from SEGV. |
| 22:32.29 | pcercuei | oh cool |
| 22:35.08 | mth | pcercuei: does suspend still work on Dingoo A320 with current kernels? |
| 22:35.37 | pcercuei | it's hard to say. Upstream Linux doesn't support the A320 |
| 22:36.08 | mth | I thought you might have a serial-only build for it |
| 22:36.18 | pcercuei | I have a 4.10 kernel for the A320, but it uses a lot of non-upstream stuff (new TCU drivers, new pinctrl driver) |
| 22:37.00 | pcercuei | and those drivers might be the reason why I can't suspend/resume |
| 23:41.54 | DocScrutinizer05 | ~die |
| 23:43.35 | *** join/#qi-hardware infobot (ibot@rikers.org) |
| 23:43.35 | *** topic/#qi-hardware is Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben/atusb 802.15.4 wireless, anelok and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware |
| 23:43.35 | *** mode/#qi-hardware [+v infobot] by ChanServ |
