Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make "next-error" and "previous-error" work when visiting files that contain results of "pdfgrep" #3

Open
rodrigo-morales-1 opened this issue Nov 13, 2020 · 1 comment

Comments

@rodrigo-morales-1
Copy link

rodrigo-morales-1 commented Nov 13, 2020

The context

Sometimes I execute pdfgrep in multiple PDF files which contain more than 1000 pages. For this reason, I want to save the results in order to visit the search results another day.

Creating the file (let's say, A) that contain the results of pdfgrep is fairly easily since the buffer that shows the results found by pdfgrep inserts a modeline into the buffer which causes Emacs to set grep as the major-mode when revisiting the file A. The code block shown below shows the results of executing M-x pdfgrep in an arbitrary file

-*- mode: grep; default-directory: "~/Experiments/" -*-
Grep started at Thu Nov 12 20:59:07

pdfgrep -H -n -i 'a' ~/Experiments/1.pdf 
/home/beep1560/Experiments/1.pdf:1:    Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut purus elit,
...

Grep finished with 64 matches found at Thu Nov 12 20:59:07

The problem

The problem is present when visiting a file that contain the results of pdfgrep. Executing M-g p (previous-error) and M-g n (next-error) show the following message in the minibuffer even when the buffer that shows the stored results of pdfgrep is *pdfgrep*.

Moved past last grep hit
Moved back before first grep hit

Additional context

next-error and previous-error do work when they are executed in the buffer that is immediately opened after executing M-x pdfgrep.

next-error and previous-error also work when visiting a file that contain results of M-x grep. I confirmed by doing the following:

  • Execute grep (i.e. M-x grep) in arbitrary files and save the results in a file with name results.
  • Close the buffer that shows the grep results.
  • Open the file results
  • Execute M-x next-error (i.e. press M-g n) and M-x previous-error (i.e. press M-g p). This caused the cursor to open the file and move the cursor to the line which contained the matching pattern.

The question

Is there any way to make the functions next-error and previous-error work (that is, open the PDF at the page that contain the selected result and don't show a error message in the minibuffer) when visiting a file that shows the results of executing pdfgrep?

jeremy-compostella added a commit that referenced this issue Feb 3, 2021
If the pdfgrep result is loaded from a file the locus buffer name is
not `pdfgrep-buffer-name'.

This should help with #3.

Signed-off-by: Jeremy Compostella <jeremy.compostella@gmail.com>
@jeremy-compostella
Copy link
Owner

I do not reproduce your issue. However, I was facing a buffer name issue which I have resolved with a4ca0a1.
With http://sdphca.ucsd.edu/lab_equip_manuals/usb_20.pdf and I M-x pdfgrep the test pattern. I save the result in a file opened it and ran next-error successfully. FYI, I am using emacs 27.1

-*- mode: grep; default-directory: "~/Documents/" -*-
Grep started at Wed Feb  3 10:23:18

pdfgrep -H -n -i test usb_20.pdf 
usb_20.pdf:8:      7.1.20 Test Mode Support ........................................................................................................................169
usb_20.pdf:12:       11.3.1 Full-/low-speed Latest Host Packet...............................................................................................306
usb_20.pdf:16:Figure 7-12. Transmitter/Receiver Test Fixture ................................................................................................132
usb_20.pdf:26:Table 9-7. Test Mode Selectors .........................................................................................................................259
usb_20.pdf:27:Table 11-24. Test Mode Selector Codes ............................................................................................................436
usb_20.pdf:30:    compliance with the specification through the testing program as defined by the USB Implementers Forum.
usb_20.pdf:79:      device up to the shortest period defined by the USB (125 µs microframe or 1 ms frame). The client
usb_20.pdf:131:  USB Specification revision and all applicable domestic and international safety/testing agency
usb_20.pdf:134:      Table 6-7 lists the minimum test criteria for all USB cable, cable assemblies, and connectors.
usb_20.pdf:134:          Test Description                       Test Procedure                  Performance Requirement
usb_20.pdf:134:                                        The object of this test procedure is
usb_20.pdf:134:                                        USB connectors. This test
usb_20.pdf:134:                                        The object of this test procedure is    level.
usb_20.pdf:134:                                        to detail a test method to prove that
usb_20.pdf:135:       Test Description                  Test Procedure                   Performance Requirement
usb_20.pdf:135:                                The object of this test is to detail a   100 mA. Mated test contacts
usb_20.pdf:135:                                The object of this test procedure is     temperature of 25 C. With power
usb_20.pdf:135:                                contacts.                                test.
usb_20.pdf:135:Contact Capacitance             The object of this test is to detail a
usb_20.pdf:135:                                The object of this test is to detail a   (0.492”) per minute.
usb_20.pdf:135:                                The object of this test is to detail a   (0.492”) per minute.
usb_20.pdf:136:         Test Description                  Test Procedure                 Performance Requirement
usb_20.pdf:136:                                  The object of this test procedure is   per hour.
usb_20.pdf:136:                                  to detail a uniform test method for
usb_20.pdf:136:                                  Test Condition A                       one minute.
usb_20.pdf:136:                                  The object of this test procedure is
usb_20.pdf:136:                                  Test Condition H                       connectors are subjected to 11 ms
usb_20.pdf:136:                                  The object of this test procedure is   pulses. Three shocks in each
usb_20.pdf:137:       Test Description                 Test Procedure                  Performance Requirement
usb_20.pdf:137:                                Test Condition V Test Letter A         connectors are subjected to
usb_20.pdf:137:                                This test procedure is applicable to   of three mutually perpendicular
usb_20.pdf:137:                                                                       USB connectors under test must
usb_20.pdf:137:                                Test Condition I                       be mated.
usb_20.pdf:137:                                The object of this test is to
usb_20.pdf:137:                                Test Condition A Method III            connectors under test must be
usb_20.pdf:137:                                                                       tested in accordance with
usb_20.pdf:137:                                The object of this test procedure is   EIA 364-31.
usb_20.pdf:137:                                to detail a standard test method for
usb_20.pdf:137:                                The object of this test procedure is   hour steam aging as specified in
usb_20.pdf:137:                                to detail a uniform test method for    Category 2.
usb_20.pdf:137:Solderability                   solderability. The test procedure
usb_20.pdf:137:                                test or evaluate solder cup, solder
usb_20.pdf:138:         Test Description                        Test Procedure                 Performance Requirement
usb_20.pdf:138:                                        The object of this test is to insure   Impedance must be in the range
usb_20.pdf:138:                                             test fixture (Note 1). Use
usb_20.pdf:138:                                             the cable to be tested to the
usb_20.pdf:139:       Test Description                         Test Procedure                   Performance Requirement
usb_20.pdf:139:                                       The object of this test is to insure     Refer to Section 7.1.17 for
usb_20.pdf:139:                                            test fixture (Note 2).
usb_20.pdf:139:                                            the cable to be tested to the
usb_20.pdf:139:                                            test fixture, leaving the other
usb_20.pdf:140:         Test Description                  Test Procedure                 Performance Requirement
usb_20.pdf:140:                                  The purpose of the test is to verify   High-/full-speed.
usb_20.pdf:140:                                       impedance/delay/skew test
usb_20.pdf:140:                                  2.   Connect the cable to be tested
usb_20.pdf:140:                                       to the test fixture. If
usb_20.pdf:140:                                       on the other end to the test
usb_20.pdf:140:                                       of the test fixture by
usb_20.pdf:140:                                       from it the delay of the test
usb_20.pdf:141:       Test Description                            Test Procedure                      Performance Requirement
usb_20.pdf:141:                                         This test insures that the signal on        Propagation skew must meet the
usb_20.pdf:141:                                              with test sample cable, as in
usb_20.pdf:141:                                              the test cable. Use the TDR
usb_20.pdf:141:                                         The purpose of this test is to insure       See Section 7.1.1.2 and Table 7-7
usb_20.pdf:141:   Note1:    Impedance, propagation delay, and skew test fixture
usb_20.pdf:141:             This fixture will be used with the TDR for measuring the time domain performance of the cable under test. The
usb_20.pdf:141:             end of the cable under test to convert the signal back to unbalanced form of the correct impedance to match the
usb_20.pdf:142:          ANSI/EIA-364-C (12/94)       Electrical Connector/Socket Test Procedures
usb_20.pdf:142:      American Standard Test Materials
usb_20.pdf:142:                                       Wire and Cable, Test Standard Method
usb_20.pdf:142:                                       Jacket for Telecommunication Wire and Cable, Test
usb_20.pdf:142:          UL STD-94                    Test for Flammability of Plastic materials for Parts
usb_20.pdf:149:    mode is required to test for this state at a particular point in time when it is transmitting a SOF packet, as
usb_20.pdf:153:test. The normalized V/I curve for the driver must fall entirely inside the shaded region. The V/I region is
usb_20.pdf:153:When testing, the current into or out of the device need not exceed ±10.71*VOH mA and the voltage applied to
usb_20.pdf:154:      10.71 * |VOH|              Test Limit
usb_20.pdf:154:       -10.71 * |VOH|                           Test Limit
usb_20.pdf:155:10.71 * |VOH|            Test Limit
usb_20.pdf:155: -10.71 * |VOH|                       Test Limit
usb_20.pdf:158:      the test load can be adjusted to match the actual application. Low-speed buffers on hosts and hubs that are
usb_20.pdf:158:      between 75 ns and 300 ns for any balanced, capacitive test load. In all cases, the edges must be matched to
usb_20.pdf:158:      common-mode noise that will radiate and affect the ability of devices and systems to pass tests that are
usb_20.pdf:159:   plus CL. A low-speed buffer design that can drive the downstream test load would be capable of driving any
usb_20.pdf:159:   Figure 7-11 defines four test planes which will be referenced in this section. TP1 and TP4 are the points where
usb_20.pdf:159:   When testing high-speed transmitters and receivers, measurements are made with the Transmitter/Receiver Test
usb_20.pdf:159:   transceiver being tested.
usb_20.pdf:160:               Transmitter Test Attenuation: Voltage at Scope Inputs = 0.760 * Voltage at Transmitter Outputs
usb_20.pdf:160:               Receiver Test Attenuation: Voltage at Receiver Inputs = 0.684 * Voltage at Data Generator Outputs
usb_20.pdf:160:                          Test Supply Voltage
usb_20.pdf:160:      Under Test                                                             Coax          Generator
usb_20.pdf:160:                                     Figure 7-12. Transmitter/Receiver Test Fixture
usb_20.pdf:160:      Note: When testing the upstream facing port of a device, VBUS must be provided from the time the device is
usb_20.pdf:160:      placed in the appropriate test mode until the test is completed. This requirement will likely necessitate
usb_20.pdf:160:      additional switching functionality in the test fixture (for example, to switch the D+ and D- lines between the host
usb_20.pdf:160:      controller and the test instrument). Such additions must have minimal impact on the high frequency
usb_20.pdf:160:      a driver must drive signals at each of the specified test planes. Receive eye patterns specify the minimum and
usb_20.pdf:167:   ground on D+ and D-. Figure 7-12 shows a recommended “Transmitter Test Fixture” for performing these
usb_20.pdf:172:      being tested. It is left to the tester of a specific device to determine the connector reference location by whatever
usb_20.pdf:172:      at the chip boundary shown in Figure 7-23 without USB connectors or cables. Parasitic capacitance of the test
usb_20.pdf:172:      transceiver should be in Test_SE0_NAK mode during testing.
usb_20.pdf:176:      Note 1: Measured with a 45 Ω resistor to ground at each data line, using test modes Test_J and Test_K
usb_20.pdf:176:      Note 2: Measured using test mode Test_Packet with fixture shown in Figure 7-12
usb_20.pdf:176:      Note 3: Measured with fixture shown in Figure 7-12, using test mode SE0_NACK
usb_20.pdf:193:   Such conformance is tested using Test Mode Test_Packet, as defined in Section 7.1.20.
usb_20.pdf:197:7.1.20 Test Mode Support
usb_20.pdf:197:  To facilitate compliance testing, host controllers, hubs, and high-speed capable functions must support the
usb_20.pdf:197:  following test modes:
usb_20.pdf:197:  •   Test mode Test_SE0_NAK: Upon command, a port’s transceiver must enter the high-speed receive mode
usb_20.pdf:197:      and remain in that mode until the exit action is taken. This enables the testing of output impedance, low
usb_20.pdf:197:      CRC is determined to be correct) within the normal allowed device response time. This enables testing of
usb_20.pdf:197:      the device squelch level circuitry and, additionally, provides a general purpose stimulus/response test for
usb_20.pdf:197:      basic functional testing.
usb_20.pdf:197:  •   Test mode Test_J: Upon command, a port’s transceiver must enter the high-speed J state and remain in that
usb_20.pdf:197:      state until the exit action is taken. This enables the testing of the high output drive level on the D+ line.
usb_20.pdf:197:  •   Test mode Test_K: Upon command, a port’s transceiver must enter the high-speed K state and remain in
usb_20.pdf:197:      that state until the exit action is taken. This enables the testing of the high output drive level on the D- line.
usb_20.pdf:197:  •   Test mode Test_Packet: Upon command, a port must repetitively transmit the following test packet until
usb_20.pdf:197:      the exit action is taken. This enables the testing of rise and fall times, eye patterns, jitter, and any other
usb_20.pdf:197:      The test packet is made up by concatenating the following strings. (Note: For J/K NRZI data, and for NRZ
usb_20.pdf:198:          A port in Test_Packet mode must send this packet repetitively. The inter-packet timing must be no less than
usb_20.pdf:198:      •   Test mode Test_Force_Enable: Upon command, downstream facing hub ports (and only downstream
usb_20.pdf:198:          at the hub’s upstream facing port must be repeated on the port which is in this test mode. This enables
usb_20.pdf:198:          testing of the hub’s disconnect detection; the disconnect detect bit can be polled while varying the loading
usb_20.pdf:198:      Test Mode Entry and Exit
usb_20.pdf:198:      Test mode of a port is entered by using a device specific standard request (for an upstream facing port) or a port
usb_20.pdf:198:      SetFeature(TEST_MODE) is defined in Section 9.4.9. The hub class request SetPortFeature(PORT_TEST) is
usb_20.pdf:198:      The transition to test mode must be complete no later than 3 ms after the completion of the status stage of the
usb_20.pdf:280:              TEST_MODE                                       Device                        2
usb_20.pdf:280:      Note: The Test_Mode feature cannot be cleared by the ClearFeature() request.
usb_20.pdf:286:      00000000B            SET_FEATURE             Feature        Test Selector       Zero        Zero           None
usb_20.pdf:286:      The TEST_MODE feature is only defined for a device recipient (i.e., bmRequestType = 0) and the lower
usb_20.pdf:286:      byte of wIndex must be zero. Setting the TEST_MODE feature puts the device upstream facing port into
usb_20.pdf:286:      test mode. The device will respond with a request error if the request contains an invalid test selector. The
usb_20.pdf:286:      transition to test mode must be complete no later than 3 ms after the completion of the status stage of the
usb_20.pdf:286:      request. The transition to test mode of an upstream facing port must not happen until after the status stage
usb_20.pdf:286:      of the request. The power to the device must be cycled to exit test mode of an upstream facing port of a
usb_20.pdf:286:      device. See Section 7.1.20 for definitions of each test mode. A device must support the TEST_MODE
usb_20.pdf:287:                                          Table 9-7. Test Mode Selectors
usb_20.pdf:287:         01H          Test_J
usb_20.pdf:287:         02H          Test_K
usb_20.pdf:287:         03H          Test_SE0_NAK
usb_20.pdf:287:         04H          Test_Packet
usb_20.pdf:287:         05H          Test_Force_Enable
usb_20.pdf:287:       06H-3FH        Reserved for standard test selectors
usb_20.pdf:287:      C0H-FFH         Reserved for vendor-specific test modes.
usb_20.pdf:287:   If the feature selector is TEST_MODE, then the most significant byte of wIndex is used to specify the
usb_20.pdf:287:   specific test mode. The recipient of a SetFeature(TEST_MODE…) must be the device; i.e., the lower byte
usb_20.pdf:287:   to exit test mode. The valid test mode selectors are listed in Table 9-7. See Section 7.1.20 for more
usb_20.pdf:287:   information about the specific test modes.
usb_20.pdf:287:   Default state:         A device must be able to accept a SetFeature(TEST_MODE, TEST_SELECTOR)
usb_20.pdf:329:  test at 65535 for high-speed or 16383 for full-speed is adequate). If the current (micro)frame timer has
usb_20.pdf:334:      complete by its EOF1. The time consumed by a transaction (and consequently the latest start time of the
usb_20.pdf:334:11.3.1 Full-/low-speed Latest Host Packet
usb_20.pdf:338:SetTest
usb_20.pdf:338:      Testing                                                                                             10mS.
usb_20.pdf:339:SetTest                   Hub Controller    Logical OR of SetPortFeature(Test_SE0_NAK),
usb_20.pdf:339:                                            SetPortFeature(Test_J), SetPortFeature(Test_K),
usb_20.pdf:339:                                            SetPortFeature(Test_PRBS),
usb_20.pdf:339:                                            SetPortFeature(Test_Force_Enable)
usb_20.pdf:341:   In high-speed, this state is used for testing for disconnect at the port. The disconnect detection circuit is
usb_20.pdf:343:11.5.1.14 Testing
usb_20.pdf:343:   A port transitions to this state from any state when the port sees SetTest.
usb_20.pdf:343:   was a SetPortFeature(PORT_TEST, Test_Force_Enable), the port supports packet connectivity in the
usb_20.pdf:344:                                            Testing                           TransmitR          SendEOR,
usb_20.pdf:388:      has only a single result buffered in the TT at any time. Note that the “buffer match” test is different for bulk
usb_20.pdf:388:      and control endpoints. A buffer match test for a bulk transaction must include the direction of the
usb_20.pdf:388:      transaction in the test since bulk endpoints are unidirectional. A control transaction must not use direction
usb_20.pdf:388:      as part of the match test.
usb_20.pdf:432:          determination. Periodic transactions do not need to be included in this test since the microframe
usb_20.pdf:450:               PORT_TEST                                     Port                         21
usb_20.pdf:455: 11      Port Test Mode : (PORT_TEST) This field reflects the status of the port's test mode. Software uses the
usb_20.pdf:455:         SetPortFeature() and ClearPortFeature() requests to manipulate the port test mode.
usb_20.pdf:455:             0 = This port is not in the Port Test Mode.
usb_20.pdf:455:             1 = This port is in Port Test Mode.
usb_20.pdf:457:11.24.2.7.1.9 PORT_TEST
usb_20.pdf:457:   When the Port Test Mode bit is set to a one (1B), the port is in test mode. The specific test mode is
usb_20.pdf:457:   specified in the SetPortFeature(PORT_TEST) request by the test selector. The hub provides no standard
usb_20.pdf:457:   mechanism to report the specific test mode; therefore, system software must track which test selector was
usb_20.pdf:457:   used. Refer to Section 7.1.20 for details on each test mode. See Section 11.24.2.13 for more information
usb_20.pdf:457:   about using SetPortFeature to control test mode.
usb_20.pdf:458:      This field may only be set as a result of a SetPortFeature(PORT_TEST) request. A port PORT_TEST
usb_20.pdf:463:   feature selector is PORT_TEST.
usb_20.pdf:463:   •   PORT_TEST
usb_20.pdf:463:   When the feature selector is PORT_TEST, the most significant byte (bits 15..8) of the wIndex field is the
usb_20.pdf:463:   selector identifying the specific test mode. Table 11-24 lists the test selector definitions. Refer to
usb_20.pdf:463:   Section 7.1.20 for definitions of each test mode. Test mode of a downstream facing port can only be used in
usb_20.pdf:463:       1) All enabled downstream facing ports of the hub containing the port to be tested must be
usb_20.pdf:463:       2) A SetPortFeature(PORT_TEST) request must be issued to the downstream facing port to be tested.
usb_20.pdf:463:          Only a single downstream facing port can be in test_mode at a time. The transition to test mode
usb_20.pdf:463:       3) The downstream facing port under test can now be tested.
usb_20.pdf:463:       4) During test_mode, a port disconnect or resume status change on one of the suspended ports (not
usb_20.pdf:463:          including the port under test) must cause a status change (C_PORT_CONNECTION or
usb_20.pdf:464:          status changes may or may not be supported in a hub with a downstream facing port in test mode.
usb_20.pdf:464:          The reporting of these status changes can allow a test application to restore normal operation of a
usb_20.pdf:464:          device attached to the root hub can be disconnected to notify the test application to restore normal
usb_20.pdf:464:      5) During test_mode, the state of the hub downstream facing ports must not be changed by the host
usb_20.pdf:464:         Note: The hub must also be reset before a SetPortFeature(PORT_TEST) can be used to place the
usb_20.pdf:464:         port into another test mode.
usb_20.pdf:464:      6) After the test is completed, the hub (with the port under test) must be reset by the host or user.
usb_20.pdf:464:         This must be accomplished by manipulating the port of the parent hub to which the hub under test
usb_20.pdf:464:          a)   Issuing a SetPortFeature(PORT_RESET) to port of the parent hub to which the hub under test
usb_20.pdf:464:          c)   Disconnecting and re-connecting the hub under test from its parent hub port.
usb_20.pdf:464:          d) For a root hub under test, a reset of the Host Controller may be required as there is no parent
usb_20.pdf:464:      7) Behavior of the hub under test and its downstream facing ports is undefined if these requirements
usb_20.pdf:464:                                  Table 11-24. Test Mode Selector Codes
usb_20.pdf:464:                          Value                  Test Mode Description
usb_20.pdf:464:                           1H         Test_J
usb_20.pdf:464:                           2H         Test_K
usb_20.pdf:464:                           3H         Test_SE0_NAK
usb_20.pdf:464:                           4H        Test_Packet
usb_20.pdf:464:                           5H         Test_Force_Enable
usb_20.pdf:464:                        06H-3FH       Reserved for Standard Test selections
usb_20.pdf:464:                        C0H-FFH       Reserved for Vendor-Unique test selections
usb_20.pdf:601:       removal                                           American Standard Test Materials, 6.7.1
usb_20.pdf:603:   configuration descriptors, 9.6.3, 11.23.1                buffer match tests, 11.17.1
usb_20.pdf:608:C_PORT_SUSPEND                                              test mode, 7.1.20
usb_20.pdf:612:   signaling delays, 7.1.14.1                             Electrical Connector/Socket Test Procedures,
usb_20.pdf:612:   test mode support, 7.1.20                                     Memory (EEPROM), 2.0 glossary
usb_20.pdf:613:End-of-Packet (EOP). See EOPs                               entering test mode, 7.1.20
usb_20.pdf:614:   isochronous transactions, 11.21.1, 11.21.4             exiting test mode, 7.1.20
usb_20.pdf:617:     USB device requests, 9.3 to 9.3.5                      during test mode, 11.24.2.13
usb_20.pdf:619:   cable impedance tests, 6.7 Table 6-7                       bus transactions and, 4.4
usb_20.pdf:619:   test mode support, 7.1.20                                  split transactions, 5.10, 8.4.2 to 8.4.2.3
usb_20.pdf:621:  test mode support, 7.1.20                                        11.7.1.4.4
usb_20.pdf:622:                                                            cable impedance tests, 6.7 Table 6-7
usb_20.pdf:622:                                                            test mode, 7.1.20
usb_20.pdf:622:  test mode support, 7.1.20
usb_20.pdf:625:      host controller and, 5.10                                test mode, 7.1.20
usb_20.pdf:625:                                                             test mode, 7.1.20
usb_20.pdf:625:    test mode, 7.1.20                                      kB/S and kb/S, defined, 2.0 glossary
usb_20.pdf:625:    data source jitter, 7.1.13.1 to 7.1.13.1.2             latest host packet, 11.3.1
usb_20.pdf:627:mechanical specifications, 6, 6.1                         test mode, 7.1.20
usb_20.pdf:629:  test mode packets, 7.1.20                                Phase Locked Loop, defined, 2.0 glossary
usb_20.pdf:630:         high-speed data PIDs, 8.3.1 Table 8-1                    test mode, 7.1.20
usb_20.pdf:633:PortPwrCtrlMask field                                      PORT_TEST
usb_20.pdf:633:PORT_RESET                                                   specific test modes, 11.24.2.13
usb_20.pdf:633:  testing mode, 11.24.2.7.1.9, 11.24.2.13                    USB System Software role, 4.9
usb_20.pdf:634:   tests, 6.7 Table 6-7                                   ratings, full-speed, 6.4.1, 6.4.2
usb_20.pdf:635:recovering from errors. See error detection and            Reserved test mode, 9.4.9
usb_20.pdf:636:   testing, 7.1.20
usb_20.pdf:637:  test mode, 7.1.20                                       service intervals, 2.0 glossary, 10.3.3
usb_20.pdf:637:      interface drawings, 6.5.4                             TEST_MODE, 7.1.20, 9.4.9
usb_20.pdf:637:      plug (male) contact materials, 6.5.4.3                TEST_SELECTOR, 9.4.9
usb_20.pdf:638:  PORT_TEST, 11.24.2.7.1.9, 11.24.2.13                       hub signaling timings, 7.1.14 to 7.1.14.2
usb_20.pdf:638:  TEST_MODE, 7.1.20                                          input characteristics, 7.1.6.1
usb_20.pdf:638:SetTest signal/event, 11.5 Table 11-5                        jitter, 7.1.13.1 to 7.1.13.1.2, 7.1.15 to 7.1.15.2
usb_20.pdf:639:   test mode, 7.1.20                                        tracking, 5.12.6, 5.12.7
usb_20.pdf:643:synchronization. See also synchronization types           test criteria for electrical, mechanical and
usb_20.pdf:643:  data-per-time synchronization, 5.12.7                   Test for Flammability of Plastic Materials for
usb_20.pdf:643:  endpoint synchronization frame, 9.4.11                  Testing state, 11.5.1.14
usb_20.pdf:643:  frame and microframe timer synchronization,             Test_J test mode, 7.1.20, 9.4.9, 11.24.2.13
usb_20.pdf:643:           11.2, 11.2.3 to 11.2.3.3                       Test_K test mode, 7.1.20, 9.4.9, 11.24.2.13
usb_20.pdf:643:  jitter, 2.0 glossary (See also jitter)                  test mode, 7.1.20, 9.4.9, 11.24.2.7.1.9,
usb_20.pdf:643:  SYNC field, 8.2                                         TEST_MODE, 7.1.20, 9.4.9, 9.4 Table 9-6
usb_20.pdf:643:  sync pattern, 7.1.10                                    Test_Packet test mode, 7.1.20, 9.4.9, 11.24.2.13
usb_20.pdf:643:  Transaction Translator loss of                          test planes in high-speed signaling, 7.1.2.2
usb_20.pdf:643:           synchronization, 11.18.6, 11.22.1              Test_SE0_NAK test mode, 7.1.20, 9.4.9,
usb_20.pdf:643:           isochronous transfers, 5.12                    TEST_SELECTOR, 9.4.9
usb_20.pdf:646:Transmitter/Receiver Test Fixture, 7.1.2.2 Figure          UL STD-94, 6.7.1
usb_20.pdf:647:  test mode support, 7.1.20                                     power management, 9.2.5
usb_20.pdf:648:USB System Software                                           test mode, 7.1.20
usb_20.pdf:649:   testing, 7.1.20                                           variable-length data stages, 8.5.3.2

Grep finished with 314 matches found at Wed Feb  3 10:23:20

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants