<azonenberg>
did you see my recent commits re the build stuff?
<azonenberg>
I have CTest working and integrated with CI on Linux, but didn't do the setup on Windows yet
<azonenberg>
you can close #25 once it's set up and running on windows. both tests should pass
<azonenberg>
#250*
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #scopehal
<lain>
azonenberg: excellent @ screenshots
<azonenberg>
lain: about to start writing a DSI decode
<azonenberg>
it will work on a single D-PHY Data stream
<azonenberg>
at some point in the indefinite future we can write a lane striping filter that sits between the D-PHY Data and CSI/DSI decodes
<azonenberg>
and merges bytes from different lanes into one logical stream
<azonenberg>
i.e. it will simulate a single stream at N times the rate but with only one start/end
<azonenberg>
that way we can write the upper layer decodes on logical transport layer packets which don't care about lane IDs etc
<_whitenotifier-f>
[scopehal-apps] whitequark opened issue #254: With Rigol DS1104Z, right-clicking with trigger enabled is very slow - https://git.io/JTif8
<_whitenotifier-f>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-6/±1] https://git.io/JTifr
<_whitenotifier-f>
[scopehal-cmake] azonenberg 9af8131 - Removed old files to make it more obvious this repo is no longer in use
<_whitenotifier-f>
[scopehal-apps] whitequark closed issue #254: With Rigol DS1104Z, right-clicking with trigger enabled is very slow - https://git.io/JTif8
<_whitenotifier-f>
[scopehal-apps] whitequark commented on issue #254: With Rigol DS1104Z, right-clicking with trigger enabled is very slow - https://git.io/JTiJw
<_whitenotifier-f>
[scopehal-apps] whitequark opened issue #255: With GDK_SCALE=2, trigger cannot be dragged - https://git.io/JTiJ6
<_whitenotifier-f>
[scopehal-apps] whitequark opened issue #256: "Connect to Instrument" dialog doesn't have a default button set - https://git.io/JTiJp
<_whitenotifier-f>
[scopehal-apps] whitequark edited issue #255: With GDK_SCALE=2, trigger cannot be dragged - https://git.io/JTiJ6
<_whitenotifier-f>
[scopehal-apps] whitequark opened issue #257: Fonts should respect GDK_DPI_SCALE - https://git.io/JTiU0
Kenley has quit [Read error: Connection reset by peer]
<azonenberg>
Bird|otherbox: ping
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JTi3H
<_whitenotifier-f>
[scopehal-apps] azonenberg 0791cd3 - Now pass the current Pango context to Pango::Layout::Create() so it uses the right DPI. See #257. Still more work needed to scale sizes of UI elements appropriately.
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±6] https://git.io/JTilV
<_whitenotifier-f>
[scopehal-apps] azonenberg a5267ff - Timeline: proper DPI scaling of text. See #257.
<_whitenotifier-f>
[scopehal-apps] azonenberg 9017a91 - Lots of UI scaling fixes for hi-DPI screens. See #257.
riktw has joined #scopehal
azonenberg_work has quit [Ping timeout: 256 seconds]
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #257: Fonts should respect GDK_DPI_SCALE - https://git.io/JTi4f
azonenberg_work has joined #scopehal
<_whitenotifier-f>
[scopehal-apps] nshcat assigned issue #256: "Connect to Instrument" dialog doesn't have a default button set - https://git.io/JTiJp
<_whitenotifier-f>
[scopehal-apps] azonenberg assigned issue #255: With GDK_SCALE=2, trigger cannot be dragged - https://git.io/JTiJ6
<_whitenotifier-f>
[scopehal-apps] azonenberg edited a comment on issue #257: Fonts should respect GDK_DPI_SCALE - https://git.io/JTi4f
katharin1 has joined #scopehal
<_whitenotifier-f>
[scopehal-apps] nshcat pushed 1 commit to master [+0/-0/±1] https://git.io/JTius
<_whitenotifier-f>
[scopehal-apps] nshcat d1e1a9e - Made 'connect to instrument' dialog usable with keyboard. Fixes #256
<_whitenotifier-f>
[scopehal-apps] nshcat closed issue #256: "Connect to Instrument" dialog doesn't have a default button set - https://git.io/JTiJp
<_whitenotifier-f>
[scopehal-apps] nshcat commented on issue #256: "Connect to Instrument" dialog doesn't have a default button set - https://git.io/JTiuc
<azonenberg>
katharin1: any progress on that windows build error?
<azonenberg>
also since i'm working on hi-dpi fixes now, can you do scopehal-apps:#131 as the first "real" preference?
<azonenberg>
there's scalable SVGs in the repo, i just need them cropped and rendered at 48x48 plus a pref added to specify which size to use, and then the necessary glue in OscilloscopeWindow to initialize the toolbar with one or the other
<azonenberg>
the 24x24s look pretty tiny on my laptop's 15 inch 4K screen
<azonenberg>
obviously the core of the prefs system comes first
<azonenberg>
but #131 shouldn't be difficult and it will give us a chance to try hooking up actual application logic to the prefs systme
<sorear>
yes, those macros existed 20 years ago, but they could at some point have decided "use WCHAR now, TCHAR is a compat alias"
<azonenberg>
or something along those lines, it's been too long
<sorear>
and LPTSTR ... :/
<katharin1>
sorear: well our software is over 20 years old :')
<sorear>
the L in LPTSTR is also a nice anachronism
<azonenberg>
sorear: And in LPARAM and WPARAM
<katharin1>
azonenberg: ill do 131
<katharin1>
sorear: LPCWSTR is my favourite one tbh
<sorear>
const?
<katharin1>
sorear: long pointer to const wide str :')
<azonenberg>
And LPCTSTR, which i preferred
<azonenberg>
katharin1: is it RAW winapi? like, you're writing a WndProc after creating stuff with a WNDCLASSEX?
<katharin1>
azonenberg: yes
<azonenberg>
wow
<azonenberg>
even back in 2006 i was using MFC
<katharin1>
we also have a lot of custom controls, its basically a very oldschool glscopeclient
<katharin1>
we also have waveform areas etc
<katharin1>
all written in raw winapi
<azonenberg>
the only true raw winapi stuff i've done is exploit code, and a tiny app that just displayed a window and rendered a line of text centered in the middle
<azonenberg>
as part of a tutorial that convinced me to never do it again :p
<azonenberg>
and i say this as someone who's written a Linux web server
<azonenberg>
No, not GNU/Linux
<azonenberg>
no dependencies on anything GNU or, in fact, anything but the kernel
<azonenberg>
i wrote it in raw amd64 asm and did naked int 80h's
<katharin1>
The really funny thing is how organically stuff like this grows - our application consists of over 30 COM-Server DLLs communicating with each other (urgh) and we have started writing new code as python modules
<azonenberg>
no libc, no anything
<katharin1>
its a big clusterfuck, but it needs to be supported
<azonenberg>
katharin1: reminds me of lecroy MAUI which is probably also about that old
<azonenberg>
it's also a giant amalgamation of COM
<sorear>
amd64 but int 80h?
<katharin1>
COM is a beast. Also, Im still quite young, and COM "was before my time". It was actually really difficult finding books about it
<azonenberg>
or was it syscalls? i cant remember
<katharin1>
i had to buy old used library books
<azonenberg>
it was a long time ago
<azonenberg>
it might have been i386
<azonenberg>
katharin1: lol
<azonenberg>
COM is still around, D3D is i think still raw COM internally
<sorear>
peak COM was before my time but I get the distinct impression it was an improvement on its successors
<katharin1>
azonenberg: yes, but finding any reliable information about things that go beyond basic usage is almost impossible on the internet
<azonenberg>
my first exposure to it was writing a traffic light ActiveX control for a tutorial in a visual studio '98 textbook
<azonenberg>
circa 2001-2002
<azonenberg>
Back when people thought embedding downloadable native binaries in web pages was a great idea
<azonenberg>
not that i'm thrilled about javascript but it's... not a native binary at least
<azonenberg>
I can now correctly parse DSI packets. Next step is to write a full video framegrab decode off that
<lain>
sweet
<azonenberg>
one confusing bit is that the RGB888 packets seem to be all zero
<azonenberg>
not sure if the display is in powersave mode or something as i'm looking at the underside :p
<azonenberg>
gonna try to VNC in and turn off all of that
<azonenberg>
lol
<azonenberg>
i dont want to move it
<azonenberg>
but if i move the mouse around in VNC that should help
<lain>
azonenberg: are you handling the virtual channel stufF?
<lain>
looks like CSI and DSI packet headers are identical
<lain>
guessing they also use the same ECC poly
<azonenberg>
I am handling virtual channels in that i detect VC IDs at this layer
<lain>
ah yeah I see in your ss, VC0
<azonenberg>
for the next layer you'll specify the VC you want to framegrab from
<azonenberg>
and it will filter
<azonenberg>
at some point i will probably add a full protocol analyzer view for the packet layer too
<azonenberg>
the CRC is just crc-16-ccitt
<azonenberg>
right now i assume ECC is always good and don't check it
<azonenberg>
#328 is the ticket to fix that, feel free to send a patch :p
<azonenberg>
when we do CSI, if you think you can refactor some of the DSI packet code out into a separate class or something to avoid duplication, go for it
<azonenberg>
I'm only thinking about CSI right now because i don't have any DSI sources handy
<azonenberg>
Does the general decode look like it's about the level you want though?
<azonenberg>
this, plus the protocol analyzer sidebar that i haven't implemented yet to see a scrollable list of packets
<azonenberg>
this layer is intended to be protocol focused, the next layer up will basically be video framegrab
<lain>
yeah that looks great
<azonenberg>
not bad for a few hours of work i think :)
<azonenberg>
checking the ECC is still pending though. i suck at ecc math
<azonenberg>
if you wanna send a PR it will be much appreciated :p
<azonenberg>
all i need is a function that takes in 3 bytes of data and calculates the expected ecc value
<azonenberg>
i'm not doing correction, just detection
<azonenberg>
also yeah the screen was off, that explains the all zero output
<azonenberg>
moved the mouse and started getting plausible RGB
<monochroma>
:D
<monochroma>
fullscreen some colors
<azonenberg>
oh its not just gonna be colors :p
<azonenberg>
it's gonna be better :p
<azonenberg>
but before i do the framegrab decode i need to do the protocol analyzer for DSI packets
<azonenberg>
also, thinking about memory depth for a second
<monochroma>
i meant full screen some colors for more quick sanity checking
<azonenberg>
oh i did that already, it looks fine
<monochroma>
ah
<monochroma>
yay
<azonenberg>
with this 800x480 LCD i have 32.65 us per scanline including the sync pulses
<azonenberg>
so that's 15.67 ms for a full frame
<azonenberg>
10M points at 5 Gsps is 2 ms
<azonenberg>
So 78M points for a full frame, I have 128M points of memory on the scope so i could plausible do a full framegrab
<monochroma>
:D
<azonenberg>
but the current visualization is pretty stretched vertically
<azonenberg>
so i might only grab a few hundred scanlines
<azonenberg>
no point, it'd go off the edge
<azonenberg>
with my current 2ms capture i get 61 scanlines which isnt bad, it's about 1/8 of the screen height
<azonenberg>
that's more than enough for me to finish writing the decode
<azonenberg>
anyway its about time for me to start "real" work for the day shortly so i probably won't get to it until the evening
<azonenberg>
but my goal is to by tomorrow some time, have a full DSI protocol analyzer and framegrab working
juli966 has joined #scopehal
katharin1 has quit [Quit: leaving]
<_whitenotifier-f>
[scopehal-apps] nshcat created branch kathi_dev - https://git.io/JvExD
<katharinawork>
azonenberg_work do you have any waveform data on your server somewhere? i need to test something, and dont have anything on this pc
<_whitenotifier-f>
[scopehal] azonenberg opened issue #329: Add filter for detecting whether a MIPI D-PHY interface is in the high speed state - https://git.io/JTPs8
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #329: Add filter for detecting whether a MIPI D-PHY interface is in the high speed state - https://git.io/JTPs8
<_whitenotifier-f>
[scopehal] azonenberg opened issue #330: Eye pattern: allow vertical range to be fixed - https://git.io/JTPsw
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #330: Eye pattern: allow vertical range to be fixed - https://git.io/JTPsw
<azonenberg_work>
katharinawork: I can upload a bunch
<azonenberg_work>
what do you want?
<katharinawork>
just something to be able to see a waveform
<azonenberg_work>
I also have test datasets for 1000base-X, 10baseT, 64/66b, 10Gbase-R, 8b10b, MIPI D-PHY, fan PWM/tachometer, HDMI, IPv4, I2C EEPROm, QSPI flash, DDR3 command bus, RGMII, SATA, SD card, SPI, SWD, USB full speed, and 802.11n
<azonenberg_work>
(some of those are large though)
<katharinawork>
id be interested in the I2C one tbh
<azonenberg_work>
Hmm it's 1.7 GB, let me see how much it compresses
<azonenberg_work>
it's a lot of waveforms :p
<azonenberg_work>
Making reduced versions of these test datasets is an open todo item
<azonenberg_work>
e.g. using digital vs analog probes for signals when i dont need analog voltages
<azonenberg_work>
not having more than 5-10 waveforms of moderate length at a reasonable sample rate
<azonenberg_work>
a lot of these are grossly oversampled because that was the time/div the scope was on and i didn't bother changing it :p
<katharinawork>
haha
<katharinawork>
if you cant get it to be small now its fine, its more that im interesting in playing with it
<_whitenotifier-f>
[scopehal-apps] whitequark commented on issue #257: Fonts should respect GDK_DPI_SCALE - https://git.io/JTPGQ
<_whitenotifier-f>
[scopehal-apps] whitequark commented on issue #256: "Connect to Instrument" dialog doesn't have a default button set - https://git.io/JTPGb
<_whitenotifier-f>
[scopehal-apps] whitequark commented on issue #256: "Connect to Instrument" dialog doesn't have a default button set - https://git.io/JTPZv
<_whitenotifier-f>
[scopehal-apps] nshcat commented on issue #256: "Connect to Instrument" dialog doesn't have a default button set - https://git.io/JTPZZ
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #257: Fonts should respect GDK_DPI_SCALE - https://git.io/JTPZw
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTPnN
<_whitenotifier-f>
[scopehal-apps] azonenberg f77e89d - Timeline: fixed new scaling cropping two-line cursor text
<_whitenotifier-f>
[scopehal-apps] nshcat opened pull request #258: Implemented visibility support for preferences - https://git.io/JTPCD
<azonenberg>
lain: also i think i can fix the D-PHY decode to work properly on single ended with some hacking
<azonenberg>
it will not see the LP11-LP10-LP00 transition on the start of packet fully
<_whitenotifier-f>
[scopehal-apps] nshcat synchronize pull request #258: Implemented visibility support for preferences - https://git.io/JTPCD
<azonenberg>
but if I see LP1x to LP0x i can probably call that good enough in a single ended decode
<katharinawork>
azonenberg thanks
<azonenberg>
That will allow full decoding of packet starts/ends and HS traffic, though not compliance verification or escape mode traffic, with a single ended probe on a data lane
<azonenberg>
katharinawork: that has the full eeprom traffic decode as well with address and value
<azonenberg>
so you can play around a bit with the new protocol analyzer view
<azonenberg>
And try changing the decode colors once you implement the feature for that
<katharinawork>
this is pretty awesome
<azonenberg>
you can also type filters in the top bar
<azonenberg>
basic wireshark style syntax, it color codes to show if the filter is valid or not
<azonenberg>
there's no docs for it yet but basically you can do arbitrary boolean expressions of columns and constant integers/strings
<azonenberg>
as well as a few special operations like, i think, "startswith" and "contains"
<azonenberg>
for string matching
<katharinawork>
thats really nice, good job
<katharinawork>
which part is this?
<katharinawork>
like, the eeprom
<azonenberg>
the DUT? double click the decoder properties
<azonenberg>
it should say :p
<azonenberg>
i think its a microchip 24c256
<azonenberg>
or some variant thereof
<azonenberg>
also when i poll after a write, the polling is collapsed
<azonenberg>
but you can expand the tree (it's not just a list) to see the individual polling cycles
<katharinawork>
yea i noticed, i like that tbh
<azonenberg>
you can do arbitrary summarization for protocol data, i'm still fine tuning the APIs to make it easy to implement
<azonenberg>
and it may change a bit
<azonenberg>
i have the same thing for MDIO and QSPI flash
<azonenberg>
with MDIO when you access a MMD register via the indirect registers, i collapse it into a single logical read/write
<azonenberg>
and for qspi flash i collapse consecutive status register polls into a single poll event
<katharinawork>
azonenberg: CI for current PR is completed
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #257: Fonts should respect GDK_DPI_SCALE - https://git.io/JTPlp
<azonenberg>
You can have more than one feature branch if you want, that's fine. I just wanted to clean up dead ones that nobody was using
katharinawork has quit [Quit: Leaving]
riktw has quit [Read error: Connection reset by peer]
StM_ has quit [*.net *.split]
StM has joined #scopehal
<_whitenotifier-f>
[scopehal-apps] nshcat opened pull request #259: Implemented units in the preferences system and preferences GUI - https://git.io/JTP5L
<_whitenotifier-f>
[scopehal-apps] nshcat edited pull request #259: Implemented units in the preferences system and preferences GUI - https://git.io/JTP5L